views:

414

answers:

9

I'm working on a game engine in C++ and I have methods like setColour and things that use british grammar. While I was thinking how C++ compilers mostly use the english language (correct me if I'm wrong) and how most APIs use american grammar, should I go with the flow and continue the unofficial standard in the grammar programmer high council or be a rebel?

I'm not sure which.

+8  A: 

Which naming convention you choose is unimportant. Use whichever form you're more comfortable with, so long as you are consistent, both within your own code and with any associated APIs that you work with.

greyfade
This is one case where I'm going to disagree with the consensus: why not have _both_ `doStuffColor` _and_ `doStuffColour` work, and produce identical results? This can be done with some simple `#define`s or with inline functions (or both).
Chris Lutz
@Chris: that seems unnecessary. Just pick one dictionary to use and be consistent.
kitchen
@Chris: It's an unnecessary maintenance load. Why should you have two functions that do exactly the same thing, just with different names? It's not needed. Period.
greyfade
@Chris why not have SetColor in german, and all the other langauges.
mP
Isn't it contradictory to say "naming conventions are unimportant" then say "so long as you are consistent"? Just saying...
Michael Burr
@Michael Burr: You're right, of course. My meaning was that *specific* naming conventions are unimportant. I my post (2 days ago ><).
greyfade
+8  A: 

Be a rebel! Go with your native English.

If you feel like tossing a sop at the Americans, provide cover functions with the incorrect spelling (facetiously: but just make sure they run enough slower that they prefer to use the right spelling).

Jonathan Leffler
+1 for "do it both ways." That's probably the best way in this case.
Chris Lutz
@Chris: really? How about `localize` vs `localise`? (A variant spelling within British English, as well as a British-American difference). Do you always remember to make those #defines too? What about Grey vs. Gray? Or let's not forget EU harmonization: Gris, Grau, Grigio, Šedá (I confess, the last one I looked up). I think this could rapidly get out of hand.
Steve Jessop
Hmm, for C++0x how about `std::list`, `std_en::list`, `std_es::lista`, `std_de::Liste`, and so on ;-)
Steve Jessop
@Steve Jessop: How interesting it would be to see `std_ja::リスト`
dreamlax
+4  A: 

It really doesn't matter which you choose, but just make sure you remain consistent.

Kyle Lutz
+2  A: 

Definitely the smartest thing to do is to pick one convention and stick with it (and also document it). C++ only "uses" a small numbers of reserved keywords. Everything else is up to you (but of course a crazy naming convention will just infuriate those who come after you).

To make a more general point, though, there is absolutely no reason to change the way you are used to spelling things. I've heard of many cases where people inherited code whose comments were in French or German: now that could be an issue in terms of maintenance!

EDIT: A point I believe is not touched upon by all the answers that say you should just stick to the American spelling: there are many cases where (to the best of my knowledge) American spelling itself has not converged, e.g. "parameterize" vs. "parametrize" (and note that I used "z", so both of these are American spellings).

Alexandros Gezerlis
+17  A: 

You should use the American spelling of color. 99% of code out there uses this, even including much of the code written by British or Australian English speakers. If you use something different, you (or someone else that uses your code) are just going to end up forgetting which to use at some point and making a needless mistake.

Tobias Cohen
+1 As a New Zealander (we use the British spelling) I would always try and persevere with the 'correct' British way until one day I realised how ridiculous it was - just use color. The great majority of code already uses it, it's shorter, and I don't often submit my code in English classes.
gacrux
+1 This is especially true if you're working with something like the Java API which already uses `color`. Mixing your own `colour` with the API's `color` is asking for trouble. (I'm Australian btw.)
David Johnstone
I agree and this is how I work, but it still does make me sad though... Especially during all the times I'm debugging and end up finding a "typo" of colour :(
Ganesh Shankar
+1. "Color" is the de-facto standard and will be used in most APIs already. In general, American English is the standard for all code worldwide, for historical and other reasons.
Max E.
Now that we're well on the way to fixing everyone's spelling of 'color', maybe we can start on weening you away from the metric system and overly colorful currency (6 shades of green are enough for anybody). We'll work on 'bonnets', 'boots', and 'chips' later. I promise to let you continue using 'football' incorrectly.
Michael Burr
@Michael Whilst "Color" is the de-facto standard in programming, be aware that some people can be quite possessive of their grammar and spelling - It's not our fault the yanks couldn't get it right :p (excuse me while I put my flame suit on)
Basiclife
@Michael: I hope you're aware that we Americans are the ones using "football" incorrectly, and each region of the USA and the English-speaking world has its own slang, dialectical variations, etc. Also, the word you're looking for is "weaning."
Seth Johnson
@Seth: it's called "football" because it's not played on horseback. As far as I'm concerned, anyone can call anything football. The one exception is that whatever Detroit does, I don't think is football.
Steve Jessop
Most coders that don't speak english natively learn the american english.
M28
+8  A: 

I'm British, and I think the right thing to do is to grit my teeth and use Color. I wouldn't normally expect a German-speaking programmer to use Farbe in a public API[*] and I wouldn't expect to have to provide alternative spellings like finalize vs finalise or localization vs. localisation.

The compiler will point out any mistakes, so I think providing alternative names for things is misguided. Come to think of it, it could even hinder some programmers since IDE auto-completion will have more to chew on. If you're going to use a single spelling hten "Color" is such a common word in APIs, commonly spelled without the "u", that it's wilful idiosyncrasy to spell it any other way. It doesn't help anyone much.

Obviously there's no clinching argument - you can call your functions method001, method002 if you like, and the code will still work, so Colour is a minor quirk by comparison. But there's a fine line between "quirky" and "misanthropic".

[*] Just because he finds it more readable than Color, I mean. If he doesn't speak English at all, he has no choice.

Steve Jessop
+1 from a Canadian.
Asaph
+2  A: 

As an Australian, I have the same considerations.

At work, we do not use US spelling, largely as it is not second nature for us to spell this way, so it would (theoretically) take longer to code if we stick with US convention, as we will always have to second guess ourselves. In doing so, we don't appear to have any problems jumping between our APIs and external US convention style libraries, but if you think you might, that will need to be a consideration.

I believe you should go with what ever comes naturally, as that will be easier for you.

And if that means sticking with your UK spelling, do so with a touch of pride ;)

johnc
+1  A: 

Why not internationalise your method names. I propose two options for this. * Name your methods in the following manner 'method1", "method2" and provide different cheat sheets for different locals, so that the British one would have method1=setColour, while in America they would see method1=setColor.

Another option is to use something like ASM to rewrite the class files inside your jar files so that for americans the method is "setColor" while in Britain and the rest of the Commonwealth they see "setColour". This would remove the need for duplicate setColor/setColour as someone else has suggested.

mP
+1  A: 

My rule, as a Canadian, is to use "color" in identifiers and "colour" in comments. For instance:

/// <summary>Return the colour in CIE Lab space.</summary>
public GetLabColor() : double * double * double;
Don Reba