Actually, that would more likely be "HoleFarbe()"; and no, we don't ;)
I use American English in my code, since its what the framework uses
and it may help future developers to maintain the code if they don't
speak German for whatever reason.
English is pretty much the lingua franca of our day, so I don't see a
problem with that approach.
The only frustrating thing is that many Germans don't really speak
English all that well, so sometimes you do end up with terribly named
functions or database fields/tables.

Kevin Wienhold

The problem is being able to remember how you yourself did it.  When in
England, I still write programs in American spelling because I don't want to
get 2 spellings of the same name into the same program.

As has been observed, the CLR forces some American spellings on us, such as
Color.

On Fri, 07 Mar 2008 22:15:59 -0500, Arne Vajhoj <arne@vajhoej.dk>
wrote:

I'm a strong supporter of Esperanto for instance method definitions,
Kikongo for local variable definitions, Kalaallisut for member
variable definitions, and Hebrew for static variable defintions, and
Swahili for static member definitions.

Having said that, we do have had some difficulty finding people who
are comfortable with all these languages, so for the moment we make do
with American English.

Why?

I can certainly see why you would want to use words from the Framework
for concepts that are covered by the framework.  But for problem
domain concepts, why bother translating them to English - particularly
as there may not /be/ an equivalent word in English.

Well, correctness trumps everything, but consistency is pretty near
the top of my list of desiderata.

I certainly regard a careful choice of names as important.