为什么许多编程语言区分大小写？

这里有很多人认为，对于同一事物使用不同的大写方式会导致问题，例如：

person
perSoN
PERSON

如果这些都指向代码中的不同对象，那将是非常糟糕的。如果你有变量person、perSoN和PERSON分别指向不同的东西，那么你就有了一个问题。

学习总是以实例为基础，下面就是一个示例：

C#（区分大小写但可从不区分大小写的VB.NET中使用）：

CONSTANT_NAME
IInterfaceName // Uses I prefix in all case sensitive and insensitive languages
ClassName      // Readable in both case sensitive and insensitive languages
_classMember   // sometimes m_classMember or just classMember
DoSomething(someParam) // Method with action name, params can be _someParam
PropertyName   // Same style in case sensitive and insensitive languages
localVariable  // Never using prefix

Java和JS使用类似于C#的风格，但方法/函数/事件的声明方式类似于变量doSomething、onEvent。

ObjectPascal（Delphi和Lazarus/FPC不区分大小写，类似于ADA和VB.NET）

CConstantName     // One can use Def or no prefix, not a standard
IInterfaceName
TClassName        // Non-atomic types/classes have T prefix e.g. TStructRecordName
PSomePointer      // Pointers have types, safer low level stuff
FClassFieldMember // F means Field member similar to m
DoSomething(Parameter) // Older code uses prefix A for parameters instead
PropertyName
LLocalVariable    // Older code uses prefix for parameters not local vars

只使用OneCase和每种类型的前缀在所有语言中都是有意义的。即使是没有前缀的语言也有像接口这样的新构造，它们不依赖于大小写而使用前缀。

因此，一个语言是否区分大小写并不重要。对于那些过于复杂以至于仅靠大小写难以表达的新概念，需要使用前缀。

既然区分大小写的语言开始使用前缀，就有理由停止使用相同标识符名称的大小写形式，例如someIdentifier，SomeIdentifier，SOME_IDENTIFIER，ISomeIdentifier，而是在合适的地方使用前缀。

考虑以下问题： 您有一个名为something的类成员、一个名为something的方法/函数参数和一个名为something的本地变量，哪种大小写约定可以轻松区分它们？ 使用最一致的大小写风格并添加前缀不是更容易吗？

大小写不敏感语言的支持者关心代码质量，他们只想要一种风格。有时，他们会接受一个库编写得很差但使用严格风格的事实，而该库可能没有风格或代码质量较差。

无论是区分大小写的还是不区分大小写的语言都需要严格的纪律，使用相同的风格更有意义。如果我们有一种只使用StrictCase、在任何地方都使用一种风格和前缀的语言，那么会更好。

有很多质量较差的C代码，大小写敏感使其难以阅读，而且你无法做任何改变。在一个不区分大小写的语言中，你可以强制执行良好的代码风格，而无需重写库。 在一个严格区分大小写的语言中，这种语言目前还不存在，所有代码都将具有良好的质量 :)

因为许多人认为employeeSocailSecurityNumber和employee_social_security_number一样易读，而且更短。

按照典型的编码标准，Person将是一个类，person将是一个变量名，PERSON将是一个常量。通常使用相同的单词但大小写不同来表示相关但略有不同的含义。
因此，如果您的企业有三个名叫罗伯特的员工，您会称他们为Robert、robert和ROBERT吗？并且依靠人们准确知道您指的是哪个？
如果您的电子邮件系统区分大小写，您会给他们分配电子邮件地址，例如Robert@widgets.com、robert@widgets.com和ROBERT@widgets.com吗？
未经授权的个人数据泄露的潜在风险将是巨大的。更不用说如果您将数据库根密码发送给即将被解雇的不满员工。
最好称呼他们为Bob、Robbie和Robert。如果他们的姓氏是Arthur、Banks和Clarke，则最好称呼他们为Robert A、Robert B和Robert C。
真的，为什么要采用容易出错或混淆的命名约定，这需要人们非常警觉？您的词汇表不够丰富吗？

关于那个提到所谓方便的技巧"MyClass myClass"的人 - 为什么，为什么，为什么？你故意让人难以一眼看出使用的方法是类方法还是实例方法。

此外，你失去了向下一个阅读你代码的人更多地介绍该类特定实例的机会。

例如：

Customer PreviousCustomer

Customer NewCustomer

Customer CorporateCustomer

你的实例名称最好能告诉同事更多信息，而不仅仅是它所基于的类！

我的类 MyClass; 如果使用不区分大小写的编译器将是不可能的。
或者你可以聪明一点，实际上使用两个不同的单词...更好地展示你实际上想要做什么，比如：
我的类 MyClass myCarDesign;
当然。

你也可以（愚蠢地）为所有类、变量、函数和方法使用单个字母（“a”、“b”和“c”）。

但是，为什么要这样做呢？

使用有意义的名称，而不是：

function a(a)
{
    int a = a.a;
    return a
}

如果单词之间的分隔不重要，那么为什么我们要在单词之间加空格呢？因此，我认为在名称中单词之间使用下划线确实可以增加可读性。而且，小写字母与适当字符的大写是最容易阅读的。最后，如果所有单词都可以通过口头传达，那肯定会更容易 - “企业_客户”而不是“大写C小写o小写r小写p小写o小写r小写a小写t小写e_大写C小写u小写s小写t小写o小写m小写e小写r”！ - 前者可以在“脑海中”说出来，而后者则不能 - 我想知道那些满意于大小写敏感性的人如何处理这些大小写敏感的名称 - 我真的很困难。所以我觉得大小写敏感性根本没有帮助 - 在我看来，这是从COBOL退步了。

因为人们经常过度思考问题。

当大小写不敏感性与类型和变量命名空间的分离相结合时，它的效果最佳。这意味着：

• 如果您将一个类声明为“TextureImage”，然后尝试将其用作“textureImage”，IDE 可以自动更正您。这使您具有优势，即除非您正在声明标识符或使用下划线，否则永远不必按 Shift 键。

• 就像在 Java 和其他几种语言中一样；键入“MyClass myClass”是完全有效的。IDE 和编译器应该没有问题区分类型和变量的使用。

此外，大小写不敏感性保证了“o”和“O”永远不会引用不同的对象。常见的争论包括：

• "sOmEoNe wIlL tYpE cOdE lIkE tHiS"; => 而且那些人将永远不被允许加入编程团队，所以这是一个伪命题的论点。即使他们设法这样做了，大小写不敏感更多是解决方案而不是问题，因为这意味着您不必记住他们使用的任何疯狂的大写/小写组合。

• "you can't internationalize case insensitivity easily!"; => 超过95％的编程语言都是用英语编写的，原因很简单。没有竞争的字符编码，地球上绝大多数键盘都是基于英语的（部分或全部）。支持Unicode标识符可能是21世纪任何人想出的最愚蠢的想法；因为好几个Unicode字符是见鬼的不可见代理，读代码足够难了，而不必使用谷歌翻译，编写代码足够难了，而不必复制和粘贴标识符或使用字符映射。

• "but case sensitive languages have more identifiers!"; => 不，它们具有语法上重载的标识符，这相当糟糕。

我不使用任何不区分大小写的编程语言，但是如果你认真思考这种事情，优点是显而易见的。

一个合理的答案可能是，语言的设计者认为这样做会使语言更易于理解，考虑到未来的发展 :)

编程语言区分大小写的另一个原因是，ID可能存储在哈希表中，而哈希表依赖于哈希函数，对于不同大小写的ID会产生不同的哈希值。在运行它们通过哈希函数之前，将所有ID转换为全大写或全小写可能并不方便。当我编写自己的编译器时，我遇到了这个问题。将我的语言声明为区分大小写更加简单（懒惰）。