为什么很多语言都区分大小写？
为什么很多语言都区分大小写？
这只是一个inheritance问题吗？ C ++是区分大小写的，因为C是，Java是区分大小写的，因为C ++是等等。 还是有更实际的原因呢？
Unix的。
Unix是区分大小写的，在Unix上开发的许多编程语言都区分大小写。
计算机不能宽容 – 大写字符与小写字符不同，它们完全不同。 而在处理周期回来的时候，内存等等都是昂贵的，不值得强迫编译器和计算机“宽容”，人们只是想让这些东西运行起来。
注意，在Visual Basic之类的事情出现之前，大小写不敏感并没有真正成为有用的东西 – 一旦公司开始投入到让群众进行编程这个概念，这对他们的底线是一件好事（例如，如果微软赚了更多的钱，在Windows上有更多的程序）的语言开始变得友好和更宽容。
我不认为你会得到比“更好的答案”，因为那个语言的作者认为这样做更好。“ 我个人认为他们是对的。 我讨厌在同一个源文件中的任何地方find这些行（并引用相同的对象+方法）…
SomeObject.SomeMethod(); ... SOMEOBJECT.SOMEMETHOD(); ... someObject.someMethod(); ... sOmEoBjEcT.sOmEmEtHoD(); 我不认为有人会很高兴看到这个…
一个有趣的事情要考虑的是，英语也是区分大小写的。 （我怀疑大多数自然语言都是如此，但是对所有人来说都不是这样）。
有一个很大的差异（我住在哪里，无论如何，靠近雷丁镇）之间：
我喜欢读书。
和
我喜欢读书。
同样，虽然很多人不正确地利用资本，而且通常你可以理解什么是意思，但这并不意味着这样的写作被认为是正确的 。 当谈到这种事情时，我是一个坚强的人，当然，这并不是说我自己的一切都是正确的。 我不知道这是否是程序devise语言区分大小写的inheritance的一部分，但我怀疑它可能是。
编程语言区分大小写的一个明显的优点是文本也变得文化不敏感。 偶尔拼出一个编译器文本编码用于源文件是不够的 – 必须指定它在哪个文化将更糟：
对于开发人员和语言语法规范来说，这实际上是非常实用的：小写/大写的区分为标识符命名增加了很多performance力。
从语言语法的angular度来看，您可以强制某些标识符以大写或小写开头（例如Java类名称）。 这使parsing更容易，从而有助于保持语法清晰。
从开发人员的angular度来看，这允许大量方便的编码约定，使您的代码更清晰，更易于理解。
我的猜测是区分大小写会扩大名字空间。 一个很好的窍门，如
MyClass myClass;
对不区分大小写的编译器来说是不可能的。
案例折叠只有英文简单（所有字符<128）。 德文sz或“sharp s”（ß）在ISO 8859-1字符集中没有大写字母变体。 经过大约十年的讨论后，它才收到了一个Unicode（现在，所有的字体都必须更新…）。 汉字和平假名（日文字母）甚至不知道小写字母。
为了避免这种混乱，即使在这个Unicode时代，允许大小写折叠和 unicode标识符也是不明智的。
当parsing和编译是真正的昂贵并且需要整夜的时候，如果编译器不必担心大小写的话，这对编译器来说是有利的。
一旦标识符通过他们的情况出现，而这些标识符是唯一的，那么返回就变得非常困难。 许多开发人员喜欢它，似乎没有一个大的愿望去解决它。
ExpertSexChange
我相信这是Stack Overflow的竞争对手，你必须付钱阅读答案。 嗯…不区分大小写，网站名称的含义是模棱两可的。
这是语言区分大小写的一个很好的理由。 不太模糊！ 对程序员的歧义被认为是糟糕的。
大小写敏感性通过使用命名约定增加了语言的可读性。 你不能写
Person person = new Person("Bill");
如果你的语言不区分大小写，因为编译器将无法区分类名和variables名。
而且，拥有人，人，人，人，人都是等效的东西，会让我头疼。 🙂
我的资本forms是什么？ 我 （U + 0049）或者（U + 0130）？
大小写取决于语言环境。
许多（非编程）语言（例如使用罗马字母的欧洲语言）区分大小写，因此这些语言的母语使用大写/小写区别是很自然的。
编程语言不区分大小写的思想是由于早期硬件（包括使用5位字符代码的电脑前电传打字机）的限制而产生的历史人为因素。
争辩病例盲人的人必须无法区分
IAmNowHere
从
IAmNowhere
（ 这是个玩笑！ 😉
因为他们像一盒青蛙一样愚蠢 ，正因为这个线索中相反的观点给出的理由（我甚至不会问这是什么，木头是树木和所有这些）。
当FOOBAR = FooBar = foobar时，您可以select您的惯例，其他编码人员也可以做同样的事情， 无论他们是否分享您的偏好 。 没有混淆。
在同一个文件中，同样具有相同名称的常量，函数和variables的天才中风也不能脱身，尽pipe具有不同的上限。 再次，没有混淆。
你打电话给你的variables网站，他们打电话给他们的网站，哪个系统感到困惑？ 扫描时也不容易。
至于查找，在查看之前将名称转换为小写是否真的有更多的处理？ 做自己不成熟的优化是一回事，期望从你select的语言的开发者那里得到的是另一个层面的错误。
…然而，所有这些答案都表示区分大小写会减less混淆。 叹
还有Common Lisp，这是一个区分大小写的语言，许多人错误地认为它是不区分大小写的。 当你input(car x)到听众，它变成(CAR X)进行处理。 可以使用小写名称来定义符号，但必须用类似于|lower-case-symbol|名称来引用它们 。 因此，input(car x)或(CAR X)或(Car X)都是一样的。
（Franz Lisp曾经介绍过他们所谓的“现代”大写字母，在这个大写字母中，Listener不会折叠，CL的关键字是小写字母，我从来没有跟上过，知道那里发生了什么。
信件的大写字母不是一个普遍的概念 。 Java使用Unicode，所以如果你想不区分大小写的Java，你的程序的含义可能会改变，取决于它编译的语言环境。
大多数语言不会让你把点或逗号（或撇号或空格）在整数文字的中间，可能是因为这也是语言环境相关的。
从.NET Framework开发人员指南大小写惯例 ，区分大小写：
大写化准则的存在仅仅是为了使标识符更易于阅读和识别。 套pipe不能用作避免库元素之间名称冲突的方法。
不要以为所有的编程语言都区分大小写。 他们不是。 姓名不能单凭个案而有所不同。
如果你没有帽子，你怎么叫？！ spring来了！
你必须有performance力。 但是，诚实地说，世界上所有的人，那些从事编程逻辑工作的人都会第一个坚持认为差异实际上是不同的。
区分大小写并不能真正帮助案例一致性。
Foo.Bar foo.Bar fOO.bAR
易于编辑自动修复的大小写不敏感的语言。 在解决这个问题的大小写敏感的语言是很难的，因为它可能是合法的。 如果foo.Bar和fOO.bAR存在，并且必须猜测你input了错误的大小写，而不是忘记声明variables（因为Foo与fOO不同），编辑器首先必须重新编译。
这里有很多人说过，用几种forms的大写字母来表示同样的东西是不好的，例如：
person perSoN PERSON
如果这些代码都引用了不同的对象，那么真的很糟糕。 如果你有variablesperson，perSoN和PERSON都指向不同的东西，你有一个问题。
我见过的每一个支持区分大小写的例子都是基于希望写出不好的，不太好的代码。 如“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代码中完全有效的情况。 区分大小写的想法可以让你更公然地违背良好的编程习惯是一个反对它的论据，而不是它。
因为许多人发现employeeSocailSecurityNumber与employee_social_security_number一样可读，并且更短。
我认为有一个区分大小写的语言鼓励人们编写糟糕的代码。
Const SHOESIZE = 9 Class ShoeSize ShoeSize.shoesize = SHOESIZE call shoeSize(ShoeSize); function shoeSize(SHOEsize) { int ShoeSIZE = 10 return ShoeSize }
咄。 为了不同的目的，你想不出一个比“ShoeSize”更好的variables名？ 你可以使用十亿个不同的单词，但是你select继续使用ShoeSize？
而且你也可以（愚蠢地）为所有的类，variables，函数和方法使用单个字母（“a”和“b”和“c”）。
但为什么你想要？
使用有意义的名称 ，而不是：
function a(a) { int a = aa; return a }
还有一个原因是语言区分大小写。 ID可以存储在散列表中，并且散列表依赖于散列函数，散列函数将针对不同的情况给出不同的散列。 在通过哈希函数运行之前，将所有的ID转换为全部或全部的ID可能并不方便。 当我编写自己的编译器时遇到了这个问题。 宣布我的语言区分大小写要简单得多（懒惰）。
我已经阅读了这整个线程。 我必须相信，那些被报告认为在区分大小写方面有价值的人从来没有用真正的高级语言（根据定义是不区分大小写的）编写程序。 K＆R承认C是中等水平。 在Pascal，Delphi，Lazarus，ADA等编程之后，人们发现高度可读的代码编写起来很简单，并且可以快速运行，而不必考虑简洁的大小写结构。 毕竟，可读性是这个主题的第一个也是最后一个字。 代码是为人写的，而不是计算机。 没有问题，以不区分大小写的代码进行debugging。 当人们转向中级语言时，人们发现区分大小写没有任何优势。 但是，有相当多的时间用于debugging大小写敏感性问题。 尤其是在将来自不同编码器的模块拼接在一起时。 也有大量的受访者表示不理解大小写不敏感的含义。 只有字符az受到影响。 这些是ASCII字符的顺序子集。 机器码的三或四个字节使得编译器对这个字符范围内的情况无动于衷。 它不会改变酒吧，数字或其他任何东西。 关于其他语言和字符集的观点根本不适用于这个讨论。 编译器或中断程序将被编码，以在编译时根据是否是ASCII来临时转换或不转换字符进行分析。
我感到震惊的是像Python这样的新语言重复了K＆R所犯的错误。 是的，他们在编译器，源代码和目标代码的总RAM是1000字节的环境中保存了半个字节。 当时就是这样。 现在内存不是问题。 现在，由于不明智的原因，即使Python中的保留字也区分大小写！ 我不认为我需要使用“打印”的“For”作为variables或函数名称。 但这种可能性已经被花费在中断器上的时间花费在每个标识符的确切情况上所花费的时间保留了下来。 我觉得不好。
为了支持区分大小写，我最近阅读的是关于哈希的评论。 但是这些罕见的编码事件可以通过仔细的注意细节来处理，这似乎不值得对代码编写者必须用来编写区分大小写代码的毫无意义的审查。 两个问题的看法。 人们鼓励糟糕的编码，在代码中设置陷阱，并且需要额外的注意力转移出更大的概念。 另一方面没有缺点，在高级语言中工作完美无缺，并且灵活性不受影响。 在我看来，VHS胜过BETA的又一例。 这只是我在这里的两分钱。
学习总是比较容易，所以在这里：
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＃的风格，但方法/函数/事件被声明为variablesdoSomething，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 eg 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和每种types的前缀在所有语言中都是有意义的。 即使没有前缀开始的语言也有更新的结构，如接口不依赖大小写，而是使用前缀。
所以，如果一个语言是区分大小写的，这真的不重要。 较新的概念被添加到区分大小写的语言，这些语言太混乱了，不能单独用case来表示，而且需要使用前缀。
由于区分大小写的语言使用前缀开始，因此停止使用具有相同标识符名称的大小写是合理的。someIdentifier SomeIdentifier SOME_IDENTIFIER，ISomeIdentifier，只是在有意义的地方使用前缀。
考虑一下这个问题：你有一个名为something的类成员，一个叫做something的方法/函数参数和一个叫做something的局部variables，可以用什么样的约定来轻松地区分它们？ 只是使用最强的ConsistentCaseStyle并添加一个前缀是否更简单？
不区分大小写的语言的粉丝关心代码质量，他们只是想要一种风格。 有时候他们会接受这样一个事实：一个图书馆写得不好，使用严格的风格，而图书馆可能没有风格或代码不好。
区分大小写和敏感的语言都需要严格的纪律，每个地方只有一种风格更有意义。 如果我们有一种只使用StrictCase的语言，每种风格和前缀都会更好。
有很多不好的C代码，区分大小写不会让它可读，你不能做任何事情。 在不区分大小写的语言中，您可以在代码中强制使用一种良好的风格，而无需重写库。 在一个不存在的StrictCase语言中，所有的代码都会有不错的质量:)
看起来大多数人都认为区分大小写很重要，我同意。
然而，当你必须在正确的情况下键入内容时，这可能会很麻烦，所以我认为IDE应该让你键入错误的大小写，但是如果你点击了自动完成的快捷方式，它应该做不区分大小写的匹配。 这给了我们两全其美的好处。
MyClass myClass; 对不区分大小写的编译器来说是不可能的。
或者你可以很聪明，实际上使用两个不同的单词…更好地显示你实际上想要做的事情，比如：
MyClass myCarDesign;
咄。
按照典型的编码标准，Person是一个类，一个人是一个variables名，PERSON是一个常量。 使用不同大小写的同一个词来表示相关的内容，但是略有不同。
所以，如果你的公司里有三名工作人员都叫罗伯特，你会把他们称为罗伯特，罗伯特和罗伯特？ 并依靠人们确切地知道你的意思？
如果您的电子邮件系统区分大小写，请为他们提供电子邮件地址，例如Robert@widgets.com，robert@widgets.com和ROBERT@widgets.com。
未经授权擅自违反个人资料的可能性将是巨大的。 更不用说，如果你把数据库的根密码发送给即将被解雇的心怀不满的员工。
最好叫他们鲍伯，罗比和罗伯特。 如果他们的姓是亚瑟，class克斯和克拉克，那么最好叫他们罗伯特A，罗伯特B和罗伯特C
真的 – 为什么地球上会有一个引起错误或困惑的命名规则，这依赖于人们非常机敏？ 你的电话里有这么短的话吗？
至于提到所谓的“MyClass myClass”这个好用的技巧的人 – 为什么，为什么呢？ 您故意难以一眼就看出使用的方法是类方法还是实例方法。
另外，你失去了告诉下一个人更多地了解class级的特殊情况的机会。
例如。
客户以前的客户
客户新客户
客户CorporateCustomer
你的实例名称需要理想地告诉你的同事，而不仅仅是它所基于的类。
If word separation is not important then why do we put spaces between words? Therefore I think that underlines between words in a name do increase readability. Also lower case with Capitalization of appropriate characters is easiest to read. Lastly, it is surely much easier if all words can be conveyed by word of mouth – "Corporate Underscore Customer" rather than "Capital C Lower Case orporate Underscore Capital C Lower Case ustomer"! – the former can be spoken 'in one's head' the latter cannot – I wonder how people who are happy with case sensitivity handle these case sensitive names in their brains – I really struggle. So I feel that case sensitivity is not at all helpfull – a retrogade step from COBOL in my opinion.
Because people seriously overthink things.
Case insensitivity works best when it's also case-preserving and combined with a separation between type and variable namespaces. 这意味着：
-
If you declare a class as '
TextureImage' and then try to use it as 'textureImage', the IDE can autocorrect you. This gives you the advantage that you'll never have to hit the shift key unless you're declaring an identifier or using an underscore. -
Just like in Java and several other languages; it's perfectly valid to type "
MyClass myClass". The IDE and the compiler should have no problem differentiating between the use of a type and the use of a variable.
In addition, case insensitivity guarantees that ' o ' and ' O ' will never refer to different objects. Common arguments include:
-
"
sOmEoNe wIlL tYpE cOdE lIkE tHiS"; => and that someone will _never_ be allowed to join a programming team, so this is a strawman argument. even if they did manage to do so, case insensitivity is more the solution than the problem, because it means that you don't have to remember whatever crazy uppercase/lowercase combination they use. -
"you can't internationalize case insensitivity easily!"; => over 95% of programming languages are written in english for a very good reason. there are no competing character encodings and the vast majority of keyboards on earth are english based (in partial or whole). supporting unicode identifiers is perhaps the dumbest idea anyone has came up with in the 21st century; because a good portion of unicode characters are frikkin invisible surragates, reading code is hard enough without having to use google translate, and writing code is hard enough without having to copy-paste identifiers or use a character map.
-
"but case sensitive languages have more identifiers!"; => no, they have grammatically overloaded identifiers, which is substantially worse.
I don't use any case-insensitive languages, but the advantages are blatantly obvious if you think about this sort of thing seriously.
