为什么许多编程语言对大小写敏感？
这只是继承的问题吗？C++对大小写敏感是因为C对大小写敏感，Java对大小写敏感是因为C++对大小写敏感等等？还是有更实际的原因呢？
32个回答
9
什么是字母 i 的大写形式？ I（U+0049）还是İ（U+0130）？
大写形式取决于语言环境。
- McDowell
2
i的大写形式是U+0049，因为程序使用英语编写，并在代码中将外来单词转化为英语形式。 - Iraimbilanja
4英语中的大多数编程语言都是区分大小写，但这是否应该成为语言设计的绝对要求呢？我认为区分大小写较少模棱两可。此外，字符U+0069不等于U+0049，除了在（基于字母的）自然语言处理之外，它们为什么应该相同呢？我没有看到任何好处。 - McDowell
9
许多（非编程）语言（例如使用罗马字母的欧洲语言）是大小写敏感的，因此对于这些语言的母语使用者来说，使用大/小写区分是很自然的。
编程语言“不应该”是大小写不敏感的想法是历史遗留问题，起源于早期硬件的限制（包括使用5位字符代码的预计算机电传打字机）。
主张大小写不敏感的人必须无法区分。
编程语言“不应该”是大小写不敏感的想法是历史遗留问题，起源于早期硬件的限制（包括使用5位字符代码的预计算机电传打字机）。
主张大小写不敏感的人必须无法区分。
IAmNowHere
来自
IAmNowhere
(这只是个玩笑！ ;-)
- joel.neely
3
大小写敏感的自然语言？告诉那些发短信的青少年们。 - Iraimbilanja
大多数（非编程）语言都不是双写语言。事实上，只有欧洲和美国有双写语言。 - Varun Mahajan
除了一个小区别（下面会解释），我理解你的意思，双写法并不是所有自然语言都普遍使用的。然而，计算机编程的早期工作大部分是在欧洲和美国完成的，所以不奇怪那里的写作约定会出现在编程语言中。（双写法与单写法是一种写作体系的特征，而非一种语言特性。有些语言有多种书写形式，其中一些使用混合大小写的罗马字母形式。当然，其中一些并非本土语言。） - joel.neely
5
还有一种叫做Common Lisp的语言，许多人错误地认为它是大小写不敏感的语言。当你在Listener中输入(car x)时，它会转换成(CAR X)进行处理。虽然可以定义小写名称的符号，但必须用类似于|lower-case-symbol|的引号括起来。因此，输入(car x)、(CAR X)或者(Car X)都能正常工作。
(Franz Lisp曾经引入了他们所谓的“现代”大写规则，其中Listener不会折叠大小写，CL关键字将以小写形式出现。我没有跟进得足够好，不知道那里发生了什么。)
- David Thornley
3
由于回答不仅精准解答了问题，还富有趣味和信息性，因此点赞该注释。 - Andy Dent
读者可以随意设置：将readtable-case设置为:upcase、:downcase、:preserve或:invert。但是内置函数都是大写的，人们不太喜欢说(CAR my-list)。 - Ken
谢谢你的澄清，肯恩。我忘了提到我是指默认设置（更不用说我缺乏黑客读者的经验了）。 - David Thornley
4
我已经阅读了整个帖子。我相信那些声称在区分大小写方面有价值的人从未编写过真正的高级语言（按定义是不区分大小写的）。K&R承认C是中级语言。在编写Pascal、Delphi、Lazarus、ADA等语言后，人们会发现编写易读代码很简单，并且可以快速运行，而不必关注简洁的区分大小写结构。毕竟，可读性是这个问题的首要和最后一个关键词。代码是为人类编写的，而不是为计算机编写的。使用不区分大小写的代码没有调试问题。当人们转向中级语言时，他们会发现区分大小写没有任何优势。然而，由于区分大小写造成的问题需要花费相当多的时间进行调试，特别是当需要组合来自不同编码者的模块时。此外，似乎许多回答者不理解什么是不区分大小写。只有a-z字符受到影响。这些是ASCII字符的连续子集。大约三到四个字节的机器代码使得编译器对这些字符范围内的大小写不敏感。它不会改变下划线、数字或其他任何东西。关于其他语言和字符集的观点根本不适用于这个讨论。编译器或解释器将被编码为在编译时基于ASCII或非ASCII字符来临时转换或不转换字符以进行分析。
我对新的编程语言（如Python）重复K&R的错误感到震惊。是的，他们在总共1000字节的RAM环境中为了节省一半的字节而做出了这样的决定。但那是过去的事情了。现在内存已经不再是问题。现在，甚至Python中的保留字也区分大小写！我不认为我需要使用"For"或"Print"作为变量或函数名。但是，由于要花费时间与解释器争夺每个标识符的确切大小写，这种可能性已经得到了保留。我认为这是一个不好的交易。
迄今为止，我读过的最接近支持区分大小写的东西是关于哈希的评论。但是，这些罕见的编码事件可以通过仔细注意细节来处理，似乎不值得程序员花费无谓的精力编写区分大小写的代码。这是两种观点。一种鼓励糟糕的编码，在代码中设置陷阱，并要求将额外的注意力从更大的概念上分散开来。另一种没有任何负面影响，在高级语言中运行得非常完美，并允许灵活性，只要不会造成伤害。对我来说，这看起来又是VHS战胜BETA的一个例子。这只是我的个人意见。
我对新的编程语言（如Python）重复K&R的错误感到震惊。是的，他们在总共1000字节的RAM环境中为了节省一半的字节而做出了这样的决定。但那是过去的事情了。现在内存已经不再是问题。现在，甚至Python中的保留字也区分大小写！我不认为我需要使用"For"或"Print"作为变量或函数名。但是，由于要花费时间与解释器争夺每个标识符的确切大小写，这种可能性已经得到了保留。我认为这是一个不好的交易。
迄今为止，我读过的最接近支持区分大小写的东西是关于哈希的评论。但是，这些罕见的编码事件可以通过仔细注意细节来处理，似乎不值得程序员花费无谓的精力编写区分大小写的代码。这是两种观点。一种鼓励糟糕的编码，在代码中设置陷阱，并要求将额外的注意力从更大的概念上分散开来。另一种没有任何负面影响，在高级语言中运行得非常完美，并允许灵活性，只要不会造成伤害。对我来说，这看起来又是VHS战胜BETA的一个例子。这只是我的个人意见。
- John Painter
4
如果没有大写字母，你怎么能喊出来？啊啊啊！
你需要表现出情感。但老实说，在全世界的人中，那些与编程逻辑打交道的人会第一个坚称差异实际上是不同的。
- mvrak
4
一个字母的大写 不是一个通用概念。Java使用Unicode，所以如果你想要实现大小写不敏感的Java程序，它的含义可能会因编译环境的不同而改变。
大多数语言不允许在整数文字中间加入点号、逗号（或者撇号、空格）等字符，这可能也与本地化有关。
大多数语言不允许在整数文字中间加入点号、逗号（或者撇号、空格）等字符，这可能也与本地化有关。
- Ken
4
来自.NET Framework开发人员指南大写约定，大小写敏感性：
大写规范的存在仅是为了使标识符更易于阅读和识别。大小写不能用作避免库元素名称冲突的手段。
不要假设所有编程语言都区分大小写。它们并不是。名称不能仅因大小写而异。
- Tom A
4
我认为大小写敏感的编程语言会鼓励人们编写糟糕的代码。
Const SHOESIZE = 9
Class ShoeSize
ShoeSize.shoesize = SHOESIZE
call shoeSize(ShoeSize);
function shoeSize(SHOEsize)
{
int ShoeSIZE = 10
return ShoeSize
}
天啊，你难道找不到比“ShoeSize”更好的变量名来区分不同的用途吗？有亿万种不同的词语可以使用，但你选择继续使用ShoeSize?
- Donna
1
7根据我的经验，那些在大小写敏感的编程语言中写这种垃圾代码的人，在大小写不敏感的编程语言中并没有写出更好的代码：他们只是使用_shoesize、__shoesize、shoesize2等变量名。 - Ken
3
我看到的所有支持大小写敏感性的例子都是基于编写糟糕、不具描述性的代码的愿望。例如，“date”与“myDate”的争论 - 这两个都是同样不具描述性的，是一种糟糕的做法。好的做法是将其命名为实际含义：birthDate、hireDate、invoiceDate等等。而且，谁会想编写这样的代码呢：
Public Class Person
Public Shared ReadOnly PERSON As Person
End Class
Public Class Employee
Public person As Person = person.PERSON
End Class
令人惊讶的是，在VB.Net代码中，大小写敏感是完全有效的。认为大小写敏感允许您更加明目张胆地违反良好的编程实践是反对它而不是支持它的一个论据。
- John
3
大小写敏感并不能真正帮助大小写一致性。
Foo.Bar
foo.Bar
fOO.bAR
在一个不区分大小写的语言中，可以很容易地通过编辑器进行自动修复。在区分大小写的语言中，修复它会更加困难，因为这可能是合法的。编辑器首先必须检查 foo.Bar 和 fOO.bAR 是否存在，并且还必须猜测您是否使用了错误的大小写，而没有忘记声明变量（因为 Foo 与 fOO 不同）。
- ggf31416
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接