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!
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!