Should identifiers and comments be always in English or in the native language of the application and developers?

Question

Duplicate: Do you use another language instead of english

Related: Coding in other (spoken) languages

Given a programming language (such as Java) that allows you to use non-ASCII identifiers (class, method, variable names), and an application written for non-English users, by developers who speak English only as a foreign language at varying levels of proficiency, should you:

• Make using English mandatory for comments and identifiers?
• Use the native language of users and developers wherever possible?
• Have a comprehensive set of rules for where to use which language?
• Mix the two in whatever way feels appropriate?

Things to keep in mind:

• Identifiers in API libraries are most likely in English, and a lot of your code will be API library calls (keywords too, of course)
• Identifiers may represent domain concepts from the native-language spec for which there are no generally-agreed English translations
• Developers may not speak English well enough to write correctly and concisely in it
• New developers may not have the same native language as everyone else and may understand English better
• It may be harder to get support from vendors and/or communities like SO when the code you need help with is not in English
• ...More points?

Answer 1

I would think that you should write the code and comments in the language that everyone feels most comfortable communicating in. If it's not English, I wouldn't use it.

Answer 2

If it is an in-house project, use the language you are comfortable with.

If you decide to use two languages, I wouldnt use one language is some places and another language in other places. Instead I would comment everything in both languages.

Bottom line: Be consistent.

Answer 3

well i think that depending on the architecture of the application, you should use both.

For the classes where there is interaction with the English APIs, then i would suggest that you use English as the language. That would help with support from the API vendor and it probably requires less knowledge of the domain. For the the interface and business logic i would think that using the native language would work best.

i understand your dilemma; and trying to translate a domain on the fly is not a very good idea; lots of things can be lost in translation. I personally worked on a project where the application was written in english and so were the comments; and when business logic had to be modified it was a real nightmare to try to understand what was going on.

I think that most people would encourage you to be consistent, and i would agree, but there are always exceptions. If you are set in using one language then it would have to be the native language IMO.

Answer 4

if you want to increase the probability that anyone will be able to maintain or fix in case of emergency, use english! how many programmers do you know who don't understand technical english? in what language are your variables written? functions? and your language... isn't it mostly english? so isn't it already easier and less confusing to refer to all the englishisms in english?

Answer 5

My personal answer is to mix both in a way that feels right:

• Using the native language exclusively is not possible, due to language keywords and API libraries that are in English
• Using English exclusively is possible, but a very bad idea:
  • programmers should concentrate fully on coding and not have to deal with tricky translation issues while they do it.
  • Having a foreign language mandated everywhere is artificial and uncomfortable, and generates much more mental friction than most people would think
  • Imagine fixing a bug concerning a field that is called "Endfälligkeit" in the spec and the GUI, but "finalMaturity" in the code (and sometimes translated differently, if you're not lucky) - buried among 150 other field names consisting of domain terms that you aren't even really familiar with in your native language, let alone in a foreign one.
  • While pretty much every developer can understand English, not everyone can write well in it - comments can be hard enough to understand without such an additional barrier.
• Instead, you use both:
  • Comments are in the native language
  • So are domain terms
  • Technical stuff and code infrastructure is in English
  • If your language (as in my case, German) can be written comfortably without non-ASCII characters, avoid them in identifiers (to avoid encoding-dependant compilation problems). Using them in comments should be OK.
  • Cosistency doesn't really matter much (except for domain terms) - yes, I consider it perfectly fine to have a createEndfaelligkeitRule() method

Answer 6

Roughly a month ago I have read the book Clean Code by Robert C. Martin.

As he stated and I fully agree, you should avoid writing comments at all. Your code should be descriptive enough. In his book there are lot of examples how you can achieve this.

Comment should be used if there is something that cannot be expressed by the code.

I would write comments only in one language. Comments in one language rotten fast and comments in two or more languages will rotten even faster :)