在变量名中使用 Ñ

我想知道是什么阻止我使用“年”这个词，想知道你对它的看法：好的、坏的和丑陋的；任何关于它的意见或评论都会对我有用。

1) 与国际团队合作。

当你在一个国际团队工作时，使用哪些角色对其他团队成员来说可能是一场噩梦；并非所有键盘都具有相同的功能来访问（例如）我们心爱的 N 与梳子；所以如果你使用这个键盘：

你的北美同事使用这个：

您的合作伙伴访问Ñ. 而且，如果您使用具有非常不同字母表的计算机，问题就会成倍增长：

int 入玉口千 = 0xFf800000;
int 人王ロ干 = 0xF8000000;

我发誓这两个变量是不同的，仔细看看名字。我真的对日语没有很好的眼光，所以我认为我不能使用正确的变量。

Decimal año = 2000; // 365 días
Decimal ano = 2016; // Parte de mi anatomía

对我来说，两者之间的区别非常明显，也许其他国家的其他同事没有这么清楚。

bool flag = false; // это не является необходимым

我永远不会知道我的同事 Pavlov Provotorov 打算说什么。

public void Iͬͩͩ̽ͦ̍҉̣͙ņ̨̠̩͈̰͎̹̼̎̊͑̌̀vͪ͐ͮ̒ͣ͒͡͏̠̤̱̪̥ợ̟͔ͭ̃͌c͙̣̱̏̿ͯ̓̅̋͛a̵̝̲͚̭̗ͬ̊ͅ_̷̱̻̤̪̝̥̠͉̂̐͊ͣ͡͝ͅâ̬̱̳̮͆ͭ̕͢ͅl̟͕̳̣ͯͦ̎ͯ̄ͩ͗ͯ̕̕͞_̽ͪ̇ͫ̆҉̧̱͚̻̝̠d̮̗̜͈̝̩̦͆̓̑͐e͂҉̩̩͓͠m̛̠̣͈̠̩̂̂͋̅ô̧͍͑͌͛n̂͏͙̭i̧͉̋ͤ̏̐̍͊͘o̶͕̹̳̟͇͇̝͉ͮͩ͋͆()

我什至不想去想这个函数能做什么。

bool ? = check_error();
if (?) { // shit happens

有人会觉得这很有趣，对我来说这似乎很糟糕。

2）同伴过度依赖正确性。

我遇到Ñ了数学同事编写这样的代码的问题：

double π = 3.14159265;

尽管 π 是该常数的正确符号，但将其输入代码比令人尴尬的痛苦还要糟糕；我曾经打开一个文本文件，其中包含我无法在需要时复制粘贴的符号；但这并没有让我的生活变得更轻松或更舒适。

好吧，但是 IDE 有助于解决这个问题，对吧？假设你有：

class MathConstants
{
    public const double π = 3.14159265;
    public const double e = 2.71828;
    public const double α = ...
    public const double δ = ...
    public const double φ = ...
    public const double γ = ...
    public const double λ = ...
}

人们会期望在 IDE 中输入会MathConstants.在该点之后给我.一个数学常数列表，从而使我免于输入它们，但在我当时使用的大多数 IDE 中，在最好的情况下，是一个未知字符列表（?或），我什至使用了一个 Eclipse 版本，如果我打开一个带有奇怪□标识符的对象的成员列表，它会退出（不保存更改的文件！），所以我最终将代码更改为：

class MathConstants
{
    public const double Pi              = 3.14159265;
    public const double Euler           = 2.71828;
    public const double Phi             = ...
    public const double EulerMascheroni = ...
    public const double Conway          = ...
}

除了对 IDE 更友好之外，这意味着我不必学习希腊字母并且比单字母变量更具解释性。

3) 编码和版本控制系统。

我在源代码中遇到的另一个问题（无论是在注释中还是在标识符中）是，将代码上传到版本控制系统时，带有奇怪字符的文件已损坏，并且在签出或更新所有内容时停止编译.

通常这个问题来自平台之间不同的文本文件编码（我通常在 Windows 上工作并在 Linux 上托管版本控制服务器），通过正确配置版本控制系统并考虑版本所在平台的特性来解决它已安装。托管代码服务器......或者只是不使用奇怪的字符。

概括。

字体Ñ ñ只是一个更复杂的问题的冰山一角，即在源代码中使用 unicode 字符。这些字符可能会导致问题而不会显着提高代码质量，因此可以将它们的使用视为对大问题的小改进。

另一方面，如果我们允许西班牙字母表中的字母，如 eñe 或 ce 带 cedilla ( ç)，我们没有理由禁止其他语言的字母，这很容易升级为更大的问题。如果我们在一个国际团队中工作，一些程序员会觉得用他们的语言编程会更舒服，这对他们有利，对团队不利（抱歉，巴甫洛夫，我无法忍受你用西里尔文发表的评论）......这不是提到每个国家/地区可以有不同的键盘，或者我们使用的 IDE 可能不准备使用这些字符，甚至这些字符会使编译器发疯。

即使我们不在国际团队中工作，我们也必须考虑到大多数编程文档都是英文的，如果我们的代码是用我们的语言编写的专有字符，那么当我们编写代码时，国际社会将更难理解我们的代码。求帮助就可以了。。

结论。

我没有看到Ñ在源代码中使用或任何其他外来字符有显着优势，但只要每个使用此类代码的人都感到舒适，我也没有任何理由禁止它。

这是一个备受争议的问题。我们大多数程序员确实有避免标识符（甚至文件名......）中的“奇怪”（非ASCII）字符的传统

在“仅ASCII”方面：这种传统感觉很健康。在团队开发时（例如：一些开发人员使用 UTF-8，其他人使用 ISO-8859-1，其他人 UTF-16...）甚至在编译时（编译器必须同意编辑器），避免了与不同编码的潜在冲突。当您想要共享代码（片段）或在主要以英语处理的公共网站上提问时，它也是健康的（所以，无需进一步说明）。[*]

在“一切顺利”方面：我们在 2016 年。大多数语言（其中 C#）都支持带有 Unicode 字符的标识符，没有问题。对于任何非初学者程序员来说，Unicode 不再是一个谜，所有西班牙语程序员都应该知道，当我们编辑文本文件（可能包含非 ASCII 字符）时，我们使用的是某种编码（而且我们总是必须自己决定）。输入，不要让我们的操作系统或我们的 IDE 自己做）。从这个角度来看，在标识符中使用 Unicode 在某种程度上是可取的：因为它迫使我们在编码中保持意识和一致性（如果我们以前不喜欢 Unicode，我们还要熟悉它）。对于源代码。

就我而言，我没有反对año在C#. 但是，如果您这样做，并且当我问“您的源代码使用什么编码？”时 你不知道如何回答我，那么是的，我们有麻烦了。

[*] 请注意，顺便提一下，这些参数中的大多数也会不鼓励使用非 ASCII 字符，不仅在标识符中，而且在文字值中，甚至在注释中 - 这似乎过于严格。

我迟到了，但我想为这件事贡献我的一粒沙子。

在我看来，你应该避免在代码的标识符中使用非 ASCII 字符......你应该直接避免使用西班牙语。一切都应该是英文的。我们处于一个全球化的世界，尤其是在软件领域，你永远不知道将来谁会为你的代码工作。

在开源项目的情况下，事情很清楚：代码将从一开始就可供所有人使用，如果世界上所有不会说您的语言的程序员都无法检查，那将是一个真正的耻辱它 - 因此他们将无法向您发送改进建议或拉取请求（这对代码作者本人也不利）。

但是，即使是由拥有单一办公室且所有员工都是本地人的小公司开发的专有代码，所有代码都使用英文是有益的。如果公司在五年内发展壮大并决定在地球其他地方雇用远程员工怎么办？如果一个英国人来到西班牙生活，结果证明他是一个优秀的程序员，想在你们公司工作（我有过这种经历）怎么办？如果代码是西班牙语，则只能雇用讲西班牙语的员工。

还有另一个问题：如果您想将部分代码粘贴到网站上寻求帮助（无论是原始的 Stack Overflow，还是公司支持论坛），并且您拥有西班牙语的所有内容，您将不得不翻译所有内容时间。

这就是我的看法，多年来我所有的代码都是 100% 英文的，我发现所有这些都是优势。但我明白，生活中并非一切都是非黑即白的，在某些情况下，无论出于何种原因，代码都必须是西班牙语。在这些情况下，我同意 PaperBirdMaster 的观点：我会避免使用任何非 ASCII 字符，例如瘟疫，并将“年”写为“年”。编程已经足够复杂，工具（IDE、存储库、持续集成环境......）本身已经引起了足够多的问题，而不会冒源文件编码问题的风险。

简短的回答：程序总是用英语。不要放“año”，也不要放“annio”，更不用说“ano”，而是“year”。

一些优点：

• 它比其他语言更紧凑（“驱动程序”与“驱动程序”）。
• 如果你想分享你的代码，英语是通用的。
• 如果您复制英文的函数以将它们添加到您的代码中，则可以节省翻译它们的费用。
• 通常，API 通常是英文的，因此使用相同语言进行编程可以提高统一性和可读性（“ upload(fileTest) ”与“ upload(testFile) ”）。
• 你马上就习惯了。
• 哦，您可以省去 ASCII 字符 > 128 的麻烦。

正如您所说，在 C# 方面没有限制，但在文化上是有限制的。如果您确定您的工作团队将始终使用西班牙语，您可以使用 Ñ。现在这将引导您考虑如何处理重音，这会变得更加复杂，因为不是每个人都知道重音的使用，它可能导致声明不同的变量需要引用它. 对象。