GB英语还是美国英语？
如果你有一个API，而且你是一个拥有高度国际化观众的英国开发者，那么你的API应该是什么样的
setColour() 要么
setColor()
（以一个简单的例子来说一个词）
总部设在英国的工程师常常对自己的“正确”拼写方式有所防范，但可以认为美国的拼写在国际市场上更为“标准”。
我猜这个问题是否重要？ 其他地区的开发人员是否会拼写GB，或者通常很明显是什么意思？
应该都是美国英语吗？
我倾向于使用美英，因为这已成为其他API的常态。 作为一个英文程序员，我没有任何问题使用“颜色”，例如。
我不是母语的人。 在写作中，我总是尝试使用en-gb 。 但是，在编程中，我总是使用en-us而不是英式英语，原因很相似，因为我不使用德语或法语作为标识符。
取决于你看到你的大部分客户。 我个人比较喜欢在我的私人代码中使用英文GB（例如Color），但是我在Color上发布了外部发布的应用程序/ API /代码！
一般来说，我会成为GB拼写的坚持者，但是我认为，如果代码一致，代码会读得更好，我发现：
Color lineColor = Color.Red;
看起来比以下好很多：
Color lineColour = Color.Red;
我想最终这并不重要。
尽pipe我通常对正确的拼写很迂腐，作为英国开发者，我总是会用美国的“颜色”拼写。 在我遇到的所有编程语言中，就是这样，所以为了保持一致性，使用“颜色”很有意义。
假设这是一个Java或C＃API，那么考虑到IDE中自动完成function的普及性可能并不重要。 如果这是一种dynamic语言，或者现代IDE不是常态，那么我会select美国的拼写。 当然，我是一个美国人，所以显然是有偏见的，但是似乎我从非母语英语的开发者那里看到的大部分代码都是用美国拼写来表示variables名等。
作为英文程序员，我使用en-US作为我的软件开发人员。 美国英语几乎在所有其他API中占据主导地位，因此，坚持一种拼写方式并消除歧义就容易得多。 这是浪费时间寻找一种方法，由于拼写本地化，只发现拼写由一个字母。
我会按照目前的标准去select美国的英文拼写。 HTML和CSS被认为是拼写“颜色”的标准，其次，如果你正在使用像.NET这样的框架，那么你很有可能已经在不同的命名空间中使用了颜色。
不得不处理两个拼写的精神税会妨碍而不是帮助开发者。
Label myLabel.color = setColour();
我在使用非美英语的API方面遇到麻烦。 只是因为拼写差异。 我知道这个词是什么意思，但是不同的拼写让我出差。
我熟悉的大部分库和框架都使用美国的拼写。 当然，我是美国人，所以…美国英语是我的母语。
大部分的开发文档（就像MSDN）都是美式英语。
因此，如果您的目标是国际观众，那么留在主stream并在您的API中使用美国英语可能会更好。
我有另外一个例子：Serialise和Serialize。 🙂
我个人认为这不重要。 我从事过使用英英拼写国家的项目，他们使用英国的拼写。 它仍然是英文，由于智能感知，这并不重要。
作为一名加拿大人，我一直遇到这个问题。 当我的肌肉记忆力持续到达“你”的时候，input“颜色”是非常困难的。
不过，我倾向于采用图书馆的语言。 Java有Color类，所以我使用颜色。
如果可能的话，我尝试find替代词。 我会让 – 幻灯片。 对于颜色我可能使用色相，墨水，前景/背景…
如果不是，作为一个英国人，我会使用EN-GB，因为我在我的国家还有一些骄傲和起源。
如果要成为一个更大项目的一部分，尤其是国际项目，我会保持整个项目的一致性，其中一小部分是一个语言变体，其余部分是另一个。
我也将不得不以美英为中心，只是为了保持一致（正如其他人已经注意到的那样）。 尽pipe我是美籍英语母语的本地人，但是我已经和德国和瑞典的软件公司一起完成软件项目，在这两种情况下，偶尔的诱惑会让我的队友在代码中使用德语或瑞典语文本 – 通常是为了评论。有时也用于variables或方法名称。 尽pipe我可以说这些语言，但它真的让人眼花缭乱，并且使得一个新的非说话者变得更难。
大多数欧洲软件公司（至less是我曾经工作过的公司）的行为方式都是一样的 – 代码保持英文，这是因为如果另一位程序员join进来，代码更友好。 尽pipe如此，内部文档通常倾向于用母语来完成。
也就是说，这里的区别是关于两种不同的英语方言，而不是像在同一个源代码文件中看到两种完全不同的语言那么极端。 所以我会说，保持美国英语的API，但你的意见在GB – 英语，如果它更适合你。
我会说看看你的语言的其他图书馆如何select和遵循其惯例。
编程语言的devise者和其内置的API做出了select，用户是否是国际的，他们习惯于看到符合这个select的拼写。 您不是针对不同语言的用户，而是针对编程语言的用户。 很可能他们从内置的API中学到了很多外语，他们可能不知道美国英语和GB英语有什么不同。 不要通过改变池塘的边缘来混淆它们。
我主要使用.NET语言，.NET Framework使用美国英语拼写。 在这个平台上，我会坚持美国英语。 我不知道任何语言都是用GB英语标准化的，但是如果你们这样做的话，那么一定要和语言保持一致。
我同意“去美国”剧团。 在写电子邮件等时，我自己更喜欢en-GB，但是美式英语在所有编程圈中都是非常标准的。
尽pipe英式英语是世界各地所说的 – 我推荐使用像其他人所说的美国英语主宰市场。
绝对是美国英语。
首先，我在美国。 在我目前的项目中，它总是“色彩”，但是我们似乎无法select拼写的单词是“灰色”与“灰色”。
这实际上很烦人。
我是这些人中的一员，因为软件没有提供英式英语选项，所以每次我被迫在设置文件中使用美式英语时，心率和血压都会上升。我 ：）
然而，我个人对这个问题的看法是提供拼写，给他们setColor（）和setColour（），在其中一个代码中写下代码，然后让第二个代码传递参数。
通过这种方式，你可以保持两个组合的快乐，只要你的智能感知得到了一点时间，但是至less人们不能抱怨你使用了错误的语言。
标识符名称的语言select与受众无关，与用于开发框架或API的原始语言无关。
我不知道很多语言，但我想不出一个使用美国英语以外的语言。
由于不同的拼写引入微妙的错误的危险太大恕我直言。
函数覆盖可能很容易变成伪超载。
由于拼写的不同，configuration文件可能会失效。
在使用en-US和en-GB使用多个类定义相同概念对象的情况下可能会出现这种情况。
因此，无论是纯粹的内部使用还是外部使用，所使用的拼写必须始终与平台/框架/编译器/ API的原始语言相匹配。
如果你所有的程序员都是英国人，请使用en-gb。 如果你的代码将被英国以外的程序员看到，那么en-us将是更好的select。
一个小问题是，我们依靠翻译服务将文档复制到其他语言。 我们发现在使用en-us作为源代码时，我们会获得更好的翻译。
你需要考虑你的观众。 谁将使用这些代码，他们期望看到什么？
我在一家在加拿大和美国设有办事处的公司工作。 在加拿大制作文件和编码时，我们使用加拿大拼写（非常类似于英国英文），美国使用美国拼写法。
有些东西跨越国界，但拼写上的差异很less成为问题。 当美国人不知道Candian和英国英语的不同拼写时，它可以产生一些有趣的对话。 有时候，他们可以，但是他们坚持要改成“正确的”拼写。 这也会影响date格式（在加拿大是dd / mm / yyyy，在美国是mm / dd / yyyy）
当出现僵局时，我们通常会使用美国拼写，因为加拿大人对这两种变化都很熟悉。
我之所以select美国而不是英国英语，是因为英国观众在面对美国的拼写时，意识到这是一个美国的申请（或者认为是这样），而美国的英国拼写却认为“..嘿，那是错误的..它的颜色不是颜色'
但是像其他人所说的那样，规范。 select并坚持下去。
对于我来说，自然而然地用英国英语工作，甚至没有考虑到这一点。 但是，如果您正在开发内部程序，那并不重要。 如果您正在创build将被公开使用的API，并且您的观众是国际化的，那么为什么不实施呢？
我更喜欢美国英语。
如果你回顾几百年，你会发现这个变化与美国根本没有任何关系，很多人会这样认为。 这些变化源于欧洲的影响，尤其是法国人。 在此之前，英文单词“color”被拼写成“color”。
试图规范化将是徒劳的，因为有一半的中国孩子正在学习欧洲前期的影响力和美国对英语的理解，而另一半正在像现在这样把它当作英语来接受。
如果你觉得语言是一个问题，那么你应该考虑重量在600克的台湾公斤。 我还没有find他们如何pipe理这一个，但我希望他们从来没有雇用飞机加油人员！
我总是使用en-GB编程。 我想这是由于英国小说的沉重影响。
但是，可能不可能有两组不同的API（一个是en-US，一个是en-GB），它们在内部调用同一个函数？ 这可能会膨胀头文件，所以也许取决于预处理器的定义，条件编译？ 如果你使用C ++，你可以做下面的事情…
#ifdef ENGB typedef struct Colour { //blahblahblah }; void SetColour(Colour c); #else typedef struct Color { //blahblahblah }; void SetColor(Color c); #endif
根据客户端程序员是否定义ENGB如下
#define ENGB
他可以在他喜欢的文化中使用这些API。 也许矫枉过正这样一个琐碎的目的，但是，嘿，如果这似乎很重要，为什么不！ 🙂
