You are soooo right, it is so hard for me to even understand some times what is written. The first time I encountered this was when my father (yes I'm a second generation coder :) showed me some code he wrote years ago.
It was written in awk (some UNIX script) and it was riddled with variables like Shura (for line), Mila (for word) and more.
Apparently this was more than just easy, it was a coding standard where he worked, that is what was defined for them to work. This is still common practice in companies using COBOL and such where the code base is very old.
personally I think it is cute, but I would never write that way.
I've always thought it would be cool if keywords, variables etc could be in whatever language you wanted, with an external (or perhaps internal along with the Xml comments that already exist) mapping Xml. At design time (say in VS.Net) reads your chosen mapping.
An old Uni prof. was Italian and did a lot of stuff in Italian as you comment. I did Italian for a bit and speak some Spanish so sometimes stuff leaks in there - admittedly it DID confuse people in the physics department when they went to look at it later... especially as coding names are increasingly significant (along with doco of course!). Mapping would be cool for me, but does come with extra work - but there are a few who may like it. Maybe :)
Steven
There are problems though. Now, 'Customer' is understandable, but if you're writing an application which is just for your users using teh mother language you have to OR translate everything over (customer, order, invoice, inquiry, whatever) which can be quite a pain, OR you have to keep your mother language for these words.
This can lead to constructions like:
public void AddLakoach(...)
{
}
I'm not all for translating everything to English, it can make the code feel really alienated, especially in comments.
My suggestion: write code in Klingon ;-)
Could not agree more - I'm having to use a database with stored procedures named things like "GetBlanket" (Blanket is the danish word for form)...
It's driving me nuts!
You know, I've always wondered what code writing entirely by people from another country that would be used in house would look like. I could see C# perhaps being OK to code like that, but VB is so verbose and english based it seems like your brain would have to switch back and forth between languages when typing.
We had an indian CS professor in college who when frustrated would start writing all kinds of garbledy-gook on the chalk board and start talking Hindi. It was pretty messed up.
Maybe the localization features of .NET could be extended member names as well? ;)
Interesting. I know that English is the standard language for international flights, and now appears to be the de facto standard for programming.
What an interesting place this world would be if we all spoke the same language!
<roy>
hey, you had to learn English to program , right? might as well use it.
</roy>
I disagree. I fail to see the need for programming in english, unless you know that the project will be somehow internationalized.
Maybe every programmer in Israel speak english; but here in Spain (I suspect in other countries too) you can easily find programmers with little or no knowledge of the english language, and programming in an unknown language is really a pain...
IMO, You're partially right.
Some of the entity types should remain in Hebrew, mostly because there is no direct translation. For instance, the word Toshav (citizen, civilian, resident, settler, ...) has no direct single word in English and is better off English-ized (ugh, what a word...).
Did you know you can program in the Hebrew alphabet? We're not telling our customers that or they'll want all the variable names in Hebrew... eww...
My experience coding and consulting in Brazil and Argentina is that :
1) All programmers read some English. They don't necessarily speak it, but do read some, otherwise, how can they code? All verbs ( commands) are in English. unless the language is assembler ( where the mnemonics are abbreviations of English words) or mumps ( where there are not many words, just letter, ( most initials of English words).
2) Comments, Names of variables, subroutines, classes, etc should be in English. I had to go back once and change all my comments, names and such from Portuguese to English because I sold the code to a store in Buenos Aires, and their developer could not understand Portuguese.
OK, it is possible to work with other languages. it is possible to maintain a code in Hebrew, for example, but it is a pain. So, Why?
The only case I think this is justifiable (?) is when someone is paying you to code in a specific tongue. then, my friend, whatever you say.. show me the money..
Mauricio,
1) That's your experience, not mine. While I agree that most programmers have a rough understanding of english texts, I can think of a dozen of good programmers that can't figure out the purpose of a method just reading the name, they just read the explanation on the spanish MSDN library.
2) If you code can be sold in a foreign country, write it in English (by the way, native spanish speakers that can't read portuguese? Surprising!). But, if you are brazilian, and you are coding, let's say, a new portal for the brazilian public administration, there is no need to do it in english; most programmers in the project will read english more or less, but all of them will be, probably, native portuguese speakers so, what would be harder?
Granted, there are exceptions to every rule, but for the common stuff, unless you really really have to, stick to english. I think in the end you also make yourself as a developer more accessible to english materials. Its about personal progress as much as it is about a united coding standard that everyone can read. Make yourself do english even if it's hard. It will only get easier and you will be able to see the vast world of english material out there.
I actually like that challenge in newsgroups, when I answer posts where the poster uses variable names from another culture. It helps reinforce the concept that the variable name means absolutely nothing, it is only a convenience to the coder. At least, that helps me sleep at night, considering I continually bite my tongue when my clients insist on (inconsistently) using Hungarian conventions throughout their code. Die, "m_strCustName", die!