开发者

Colour instead of color?

开发者 https://www.devze.com 2022-12-22 18:22 出处:网络
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 w

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开发者_StackOverflow社区 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.


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.


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.


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).


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.


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 ;)


I've been using those crazy spellings they use on a small island called England for a number of reasons:

  • I work here
  • All my colleagues work here
  • Well.. it's the English language
  • We like to think we invented the internet
  • We all think we still have this huge empire and rule the world, etc
  • We don't like the yanks! >:(

However, primarily I write C#, HTML, CSS, JS, etc. I could remain stubborn and use our own spelling, but all of these languages use Americanised keywords and member names. I ended up with a bloody load of tosh!

In my C#:

public Color BrightenColour(Color colour); // eew, minging

or in my CSS:

.greyColoured { color: gray; } /* not semantic? crikey! */

or my jQuery:

function serialiseForm() {
    return $('input, textarea, select').serialize() // cor' blimey!
}

or my HTML:

<div align="center">Centre</div> <!-- goodness gracious me! -->

So, today, I finally gave in and did a solution-wide find-replace on all my old, traditional spellings. Although I don't like all my new cross-atlantic spellings, my code is now a lot cleaner :D

Tally-ho!


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


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).


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;


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消