为什么许多编程语言对大小写敏感？
这只是继承的问题吗？C++对大小写敏感是因为C对大小写敏感，Java对大小写敏感是因为C++对大小写敏感等等？还是有更实际的原因呢？
32个回答
69
我认为你不会得到比“因为那个语言的作者认为那样更好”更好的答案。就我个人而言，我认为他们是正确的。我很讨厌在同一个源文件中找到这些行（并引用相同的对象和方法）...
SomeObject.SomeMethod();
...
SOMEOBJECT.SOMEMETHOD();
...
someObject.someMethod();
...
sOmEoBjEcT.sOmEmEtHoD();
我认为没有人会高兴看到这个...
- Paulius Maruška
10
25公正地说，大小写敏感并不能防止这种丑陋的事情发生，它只是确保所有四个调用针对不同的对象调用了不同的方法。我不知道这是否是一件好事，呵呵。 :) - Adam Bellaire
6不区分大小写的编程语言不会出现这些问题，因为任何正式的 IDE 都会自动修复大小写。但是，如果你在使用记事本编辑器，你可以通过简单的查找和替换功能来修复大小写，但在区分大小写的编程语言中，这样做可能会导致代码出错。 - ggf31416
2请看我对这个问题的回答。仅通过大小写区分名称是一种不好的做法。 - Tom A
4如果多个版本的SOMEOBJECT.SOMEMETHOD()仅大小写不同但引用相同的对象/方法对，那么比这更糟糕的唯一事情就是它们引用不同的对象/方法对。 - Amarghosh
虽然这是一个旧的话题，但我认为在现代语言中继续使用大小写敏感是一个愚蠢的决定。没有任何理由这样做。你可以通过在名称中添加数字等方式来实现大小写不敏感的操作。当确实需要大小写敏感时（例如密码），它应该存在。 - Sujay Phadke
显示剩余5条评论
67
Unix.
Unix是区分大小写的，因此许多为在Unix上使用而开发的编程语言也是区分大小写的。
计算机不会原谅 - 大写字母和小写字母不是同一件事，它们完全不同。而当处理周期、RAM等资源昂贵时，强制编译器和计算机“原谅”大小写错误并不值得付出这样的努力，人们只是试图使它们正常工作。
请注意，直到类似于Visual Basic这样的东西出现后，大小写不敏感真正成为有用的东西 - 一旦公司开始投资于让群众参与编程的概念是对他们的底线有好处的事情（即，如果Windows上有更多的程序，Microsoft就能赚更多钱），语言才开始变得友好和宽容。
- Schnapple
4
8UNIX 是大小写敏感的，原因和早期编程语言大小写敏感的原因相同，而不是因为其他原因。编程语言比 UNIX 更早出现。 - AnthonyWJones
22我认为你有一点误解。最初，所有的单词都是大写的（如FORTRAN、COBOL、LISP等）。但是这样很难阅读，所以一些系统（IBM大型机）增加了大小写不敏感性，而另一些系统（Unix）则增加了大小写敏感性。系统的大小写敏感性决定了语言的大小写敏感性。但最初，这些编程语言是大小写不敏感的，只是你必须使用大写字母。 - J S
8你可以使用任何大小写形式，只要它是全大写即可？：） - idbrii
2一个大写字母在计算机外部并不等同于一个小写字母。例如，如果我在句子中放置SAP，我们知道它是一个缩写词，而不是树木中流出的物质。那些看不到大小写差异的人是文盲。他们在在线帖子中大声喊叫，并且可能无法保持软件开发人员所需的细节注意力。 - Kaz
39
有趣的一点是，英语也是大小写敏感的。(我怀疑大多数自然语言都是如此，但并非所有语言都是如此。)
在我居住的地方(靠近雷丁镇)，下面两句话有很大的区别:
我喜欢阅读。
和
我喜欢Reading镇。
同样，虽然许多人会错误地使用大写字母，通常你可以理解其意思，但这并不意味着这样的写法是正确的。对于这种事情，我是一个坚持原则的人，当然，并不是说我自己什么都做得正确。我不知道这是否是编程语言大小写敏感性的遗传，但我怀疑可能是。
编程语言大小写敏感的一个明显优点是它使文本变得文化上无歧视。必须偶尔向编译器指明源文件使用的文本编码已经够糟糕了 - 不得不指定所处的文化背景将更加糟糕 :(
- Jon Skeet
6
6日语、韩语和汉语都没有格，但这并不影响可读性。但是你的观点很有价值。 - Robert Gould
1阿拉伯语也没有大小写。小写字母是一个相对较新的发明，大约有1000年的历史。 - starblue
2有趣。那么大写和小写希腊字母之间的区别也是现代才有的吗？我很确定拉丁语只使用大写字母，但没有查证就不敢确定。 - Jon Skeet
在.NET世界中，你可以说"I Like Reading" :P - IAdapter
日语绝对有类似“大小写”的东西：平假名与片假名。 - Kaz
2@Kaz 但是在日语中，并不像用平假名写首字母然后用片假名写剩下的那样“大写”单词。 - Ruslan
29
实际上，这对于开发人员和语言语法规范来说都非常实用：大小写的区分为标识符命名增加了很多表现力。
从语言语法的角度来看，你可以强制某些标识符以小写或大写字母开头（例如Java类名）。这使得解析更容易，因此有助于保持语法清晰。
从开发者的角度来看，这允许使用大量方便的编码约定，使您的代码更清晰、更易于理解。
- Axle
4
1尽管Java语言在语法上不强制执行任何大小写规则。 - Adrian Pronk
我承认错误，有些约定是如此普遍，以至于我确信它们实际上是语法的一部分。 - Axelle Ziegler
如果您没有按照样式指南的类命名规范，Eclipse 至少会发出警告。 - Kothar
2这种特定的编码规范，仅通过大小写区分标识符，使代码变得更难阅读。请参见我对此问题的答案。 - Tom A
24
大小写折叠仅在英语中简单实现（对于所有字符 < 128）。德国的sz或“sharp s”（ß）在ISO 8859-1字符集中没有大写变体。它只在Unicode中得到了一个大写变体，经过约十年的讨论后（现在，所有字体都必须更新…）。假名和平假名（日文字母）甚至不知道小写。
为了避免这种混乱，即使在Unicode时代，允许大小写折叠 和 Unicode标识符也不明智。
- Aaron Digulla
4
我能想象到的最棘手的问题是国际化。 - Matt Ball
5在土耳其语环境中，
i和I不是相应的小写/大写字符。i-İ是一对，而ı-I则是一个。 - CodesInChaos你提出了一个有趣的观点；然而，字符之间定义等价关系并不一定意味着在一组等价字符中必须将某个特定字符视为主导字符。如果程序通常被禁止在相同命名空间中具有仅在大小写或重音符号上有所不同的标识符（因此i/İ/ı/I将全部等效，e/E/é/ê/ë等也是如此），是否会出现任何特定问题？顺便说一句，我的偏好是语言要求字形匹配，但即使... - supercat
1备用字形被视为相同。因此，如果有一个字段
myThing，使用MyThing的代码将无法编译，但编译器/IDE可以轻松地提供更改为正确形式的选项（该选项必须是唯一的）。字形变体可以是区分范围或用法的有用视觉提示，但我认为不应该依赖它们来实现这些目的。 - supercat24
我猜大小写敏感会扩大命名空间。一个不错的技巧是
MyClass myClass;
使用大小写不敏感的编译器将是不可能的。
- user3458
11
2如果类型和变量没有共享同一个命名空间，这是可能的。 - Joachim Sauer
3不难实现：编译器可以利用每个标记的位置来确定哪些是类型名称，哪些是变量名称。 - ChrisW
1你的语法高亮代码编辑器会用丰富多彩的颜色突出显示差异。 - recursive
1比如Java，确实允许你使用相同的名称来定义变量和类：String String = "String"; 是完全合法的。 - Kothar
4问：Wirth为什么在Modula-2中选择大小写敏感，尽管他早期的Pascal是大小写不敏感的？ 答：他发现一个程序需要超过26个变量。是的...这是个笑话，但其中有一点真实性。 - bendin
显示剩余6条评论
16
ExpertSexChange（专家性转换）
我认为这是 Stack Overflow 的一个竞争对手，你需要支付费用才能阅读答案。嗯...由于不区分大小写，该网站名称的含义存在歧义。
这是语言区分大小写的一个好理由。较少的歧义！ 程序员认为歧义很讨厌。
- Scott Langham
3
2该网站的名称是专家交流（Experts-Exchange），在“点繁荣”时期除外。 - peterchen
@peterchen：expertsexchange.com 以前也可以使用。后来他们放弃了。 - John Bartholomew
2正如所说，这个网站只是在原始所有者出售它的时候短暂地更换了所有权（如果我没记错的话，是卖给了JP Morgan的子公司 - 这个故事是点com繁荣的一个可怕的例子）。 - peterchen
15
在解析和编译非常耗费时间且需要整夜的时代，如果编译器不必担心大小写问题，它会更加有利。
一旦只能通过大小写来区分唯一标识符出现，回到以前就变得非常困难。许多开发人员喜欢这样做，似乎也没有很大的反悔意愿。
- AnthonyWJones
4
至少有一个人提到了技术方面。 - Gumbo
难道你不认为应该反过来吗？在解析很耗费资源的时代，将所有内容转换为大写或小写会花费太长时间。因此，你必须非常具体，变量“Foo”和“foo”不被视为相同的变量... - Luke
@Luke：我觉得你误解了我的意思。通过使_语言_区分大小写，编译器就不必担心大小写问题，因为“Foo”和“foo”不是相同的标识符。编译器可以简单地使用标识符的二进制表示。 - AnthonyWJones
这绝对是错误的事后解释。几乎所有早期语言（FORTRAN、LISP、ALGOL、大型机汇编语言）都是不区分大小写的，或者要求使用大写字母（JCL）。此外，在ASCII和EBCDIC中，转换为大写字母非常容易。 - JS0
11
区分大小写通过使用命名约定增加了语言的可读性。您无法编写
Person person = new Person("Bill");
如果您的语言是不区分大小写的，因为编译器无法区分类名和变量名。
此外，Person、person、PersoN、PeRsOn 和 PERSON 都被视为等效标记会让我头痛。
- Bill the Lizard
4
1我刚大学毕业时，曾经参与维护一个用ADA编写的程序。大部分代码都是像这样书写的，还有各种其他随意的大小写混杂在其中。每天读它都让我头痛不已。 - Ken Henderson
3强烈不同意。由于我在两种语言上的工作经验丰富，必须担心大小写标识符的差异，这使得在大小写敏感的语言中阅读陌生的代码变得更加困难。 - T.E.D.
1取决于语法。在Python中不起作用，但如果您有特殊符号或多个命名空间或其他区分它们的方法，它可以正常工作。我经常在Common Lisp中看到((list list))。 - Ken
如果编译器知道变量类型在变量名之前，那么这不是一个问题。 - Ama
9
因为它们像一盒青蛙一样愚蠢，正如本帖中给出的相反观点所述的那样（我甚至不会问这是关于什么的。只看到了树木而已）。
当FOOBAR = FooBar = foobar时，您可以选择您的约定，并且其他编码人员可以做同样的事情，无论他们是否共享您的喜好。没有混淆。
他们也不能通过在同一文件中具有相同名称的常量、函数和变量来逃避天才的一击，尽管大小写不同。再次，没有混淆。
你称你的变量为WebSite，他们称他们的为Website，哪个系统会感到困惑？扫描时也不容易捕捉到。
至于查找，将名称转换为小写后再查找真的需要更多处理吗？自己进行过度优化是一回事，但期望来自您选择的语言的开发人员进行优化则完全是另一种水平的错失重点。
...然而，所有这些回答都说区分大小写可以减少混淆。叹气。
当FOOBAR = FooBar = foobar时，您可以选择您的约定，并且其他编码人员可以做同样的事情，无论他们是否共享您的喜好。没有混淆。
他们也不能通过在同一文件中具有相同名称的常量、函数和变量来逃避天才的一击，尽管大小写不同。再次，没有混淆。
你称你的变量为WebSite，他们称他们的为Website，哪个系统会感到困惑？扫描时也不容易捕捉到。
至于查找，将名称转换为小写后再查找真的需要更多处理吗？自己进行过度优化是一回事，但期望来自您选择的语言的开发人员进行优化则完全是另一种水平的错失重点。
...然而，所有这些回答都说区分大小写可以减少混淆。叹气。
- grunties
4
1考虑一个名为Color的类、一个Label::Color函数(用于查询标签的颜色)以及一个Label::color成员变量(用于存储当前颜色)。我认为这种惯例比称访问器为"GetColor"，变量为"m_color"更易读且易写。你觉得呢？ - Iraimbilanja
2由于我经常使用大小写不敏感的编程语言，所以我认为这两种方式都很糟糕，我从不使用它们（即使在大小写敏感的语言中）。这两种方式都只是借口，让你不必真正思考这些内容的区别。 - T.E.D.
Iraimbilanja: 我觉得你不是日本人。 :-) - Ken
考虑使用下划线作为分隔符的约定。为了练习大小写不敏感性，编译器不应区分“_”和“”，否则调用this_little_function的程序员将无法将其编写为ThisLittleFunction。在我看来，这会搞砸一切。 - heinrich5991
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接