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

Question

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

这只是遗产问题吗？ C ++区分大小写，因为C是，Java区分大小写，因为C ++是等等？或者背后有更实际的理由吗？

Answer 1

我认为你得到的答案不会比“因为那种语言的作者认为这样做更好”。我个人认为他们是对的。我讨厌在同一个源文件中找到这些行（并引用相同的对象+方法）......

SomeObject.SomeMethod();
...
SOMEOBJECT.SOMEMETHOD();
...
someObject.someMethod();
...
sOmEoBjEcT.sOmEmEtHoD();

我认为没有人会很高兴看到这个......

Answer 2

的Unix。

Unix区分大小写，开发用于Unix的许多编程语言区分大小写。

计算机不宽容 - 大写字符与小写字符不同，它们完全不同。回到处理周期，RAM等昂贵的时候，不值得努力迫使编译器和计算机“宽容”，人们只是想让事情发挥作用。

请注意，在Visual Basic之类的事情出现之前，案例不敏感并没有真正变得有用 - 一旦公司开始投入这个概念，让群众参与计划对他们的底线是一件好事（即如果Windows上有更多的程序，微软会赚更多的钱）语言开始更友好，更宽容。

Answer 3

需要考虑的一件有趣的事情是英语也区分大小写。 （我怀疑大多数自然语言都是如此，但对所有人来说可能都不是这样。）

有一个很大的区别（我居住的地方，无论如何，靠近雷丁镇）：

  

我喜欢读书。

和

  

我喜欢读书。

同样，虽然许多人做错误地大写，并且你通常可以理解其含义，但这并不意味着这种写作被认为是正确的。当涉及到这种事情时，我是一个坚持不懈的人，当然，这并不是说我自己把事情做对了。我不知道这是否是编程语言区分大小写的继承的一部分，但我怀疑它可能是。

编程语言区分大小写的一个明显优势是文本也变得文化不敏感。很难不得不偶尔向编译器拼出哪个文本编码用于源文件 - 必须指定它所在的文化会更糟糕：（

Answer 4

对于开发人员和语言语法规范来说，它实际上非常实用：低/大写区别为标识符命名增加了很多表现力。

从语言语法的角度来看，您可以强制某些标识符以小写或大写（例如Java类名称）开头。这使得解析更容易，因此有助于保持语法清洁。

从开发人员的角度来看，这允许大量方便的编码约定，使您的代码更清晰，更易于理解。

Answer 5

我的猜测是，区分大小写扩大了名称空间。一个很好的技巧，如

MyClass myClass;

使用不区分大小写的编译器

是不可能的。

Answer 6

案例折叠只是简单的英文（对于所有字符<128）。德语sz or "sharp s" (ß)在ISO 8859-1字符集中没有大写变体。在大约decade of discussion之后它只在Unicode中收到一个（现在，所有字体都必须更新......）。汉字和平假名（日语字母）甚至不知道小写。

为了避免这种混乱，即使在这个Unicode时代，允许大小写折叠和 unicode标识符也是不明智的。

Answer 7

当解析和编译真的很昂贵并且需要整晚时，如果编译器不必担心大小写的话，这对编译器来说是有利的。

一旦标识符存在，只有通过他们的情况才是唯一的，它变得非常难以返回。许多开发人员都喜欢它，并且似乎没有很大的愿望撤消它。

Answer 8

<强> ExpertSexChange

我相信这是Stack Overflow的竞争对手，您必须付费才能阅读答案。嗯......在不区分大小写的情况下，网站名称的含义不明确。

这是语言区分大小写的一个很好的理由。不那么模棱两可！程序员的歧义被认为是令人讨厌的。

Answer 9

区分大小写通过使用命名约定增加了语言可读性。你不能写

Person person = new Person("Bill");

如果您的语言不区分大小写，因为编译器无法区分类名和变量名。

此外，拥有人，人，PersoN，PeRsOn和PERSON，都等同于令人头疼。 ：）

Answer 10

i 的资本形式是什么？ 我（U + 0049）或İ（U + 0130）？

大写是依赖于语言环境。

Answer 11

许多（非编程）语言（例如使用罗马字母的欧洲语言）区分大小写，因此对于这些语言的母语使用者来说，使用大/小写区别是很自然的。

编程语言不会区分大小写的想法是由于早期硬件（包括使用5位字符的计算机电传打字机）的限制而产生的历史错误码）。

争论案例盲语的人必须无法区分

IAmNowHere

这

IAmNowhere

（这是个玩笑！; - ）

Answer 12

因为他们像一盒青蛙一样愚蠢，正是出于这个主题的相反观点所给出的原因（我甚至不会问这是什么。木头为树木以及所有这些）。

当FOOBAR = FooBar = foobar时，您可以选择您的约定，其他编码人员可以执行相同的，无论他们是否共享您的偏好。没有困惑。

他们也无法摆脱具有常数，函数和变量的天才在同一个文件中具有相同名称的天才，尽管有不同的上限。再一次，没有混乱。

你调用你的变量WebSite，他们称他们为网站，哪个系统混淆了？当你正在扫描时，也不容易捕捉。

至于查找，在查找之前将名称转换为小写是否真的要多得多？做一个你自己的过早优化是一回事，期待你选择的语言的开发者是一个完全错过这一点的另一个层次。

...然而，所有这些答案都说明了区分大小写，减少了混乱。 嗟

Answer 13

还有Common Lisp，这是一种区分大小写的语言，许多人错误地认为这种语言不区分大小写。当您在监听器中键入(car x)时，它会变为(CAR X)进行处理。可以使用小写名称定义符号，但必须引用类似|lower-case-symbol|的符号。因此，输入(car x)或(CAR X)或(Car X)的工作方式都相同。

（Franz Lisp曾经介绍过他们所谓的“现代”大写，其中监听器不会折叠案例，CL关键字将小写。我从来没有很好地了解它发生了什么。）< / p>

Answer 14

字母isn't a universal concept的大写字母。 Java使用Unicode，因此如果您想要不区分大小写的Java，程序的含义可能会根据编译的区域设置而改变。

大多数语言都不允许您在整数文字的中间放置点或逗号（或撇号或空格），可能是因为它也与语言环境有关。

Answer 15

从 .NET Framework开发人员指南 Capitalization Conventions，案例敏感度：

  

存在资本化指引   仅仅是为了使标识符更容易   阅读并认识。套管不能   用作避免名字的手段   库元素之间的冲突。

     

不要假设所有编程   语言区分大小写。他们是   不。名称不能因情况而异   单独

Answer 16

如果你没有帽子怎么喊？！ AHHH！

你必须富有表现力。但老实说，在世界上所有人中，那些使用编程逻辑的人将是第一个坚持差异实际上是差异的人。

Answer 17

区分大小写并不能确保案例的一致性。

Foo.Bar  
foo.Bar  
fOO.bAR  

在不区分大小写的语言中，编辑器可以轻松自动修复。 在一个区分大小写的语言中修复它会更难，因为它可能是合法的。编辑器首先要知道foo.Bar和fOO.bAR是否存在并且还必须猜测你用错误的情况输入而不是忘记声明变量（因为Foo与fOO不同）。

Answer 18

这里的很多人都说过，对于几种形式的大写来说，引用相同的东西是不好的，例如：

person
perSoN
PERSON

如果这些都引用了代码中的不同对象，那将是非常糟糕的。如果你有变量人，perSoN和PERSON所有人指的是不同的东西，你就会遇到问题。

Answer 19

我看到支持区分大小写的每个例子都是基于编写糟糕的，不受欢迎的代码的愿望。例如“日期”与“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代码中非常有效的案例。案例敏感性使你更加公然违背良好的编程习惯的想法是反对它的论据，而不是它。

Answer 20

我认为使用区分大小写的语言会鼓励人们编写糟糕的代码。

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

function shoeSize(SHOEsize)
{
   int ShoeSIZE = 10
   return ShoeSize
}

咄。对于不同的目的，你想不出比“ShoeSize”更好的变量名吗？您可以使用十亿个不同的单词，但您选择继续使用ShoeSize？

Answer 21

通过示例学习总是比较容易，所以在这里：

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的局部变量，可以使用什么案例约定来轻松区分这些？ 是不是更容易在任何地方使用最ConsistentCaseStyle并添加前缀？

不区分大小写的语言的粉丝关心代码质量，他们只想要一种风格。有时候他们会接受这样一个事实，即一个库写得不好并且使用严格的样式，而库可能没有样式或代码不好。

区分大小写和不敏感的语言都需要严格的规范，在任何地方只有一种风格更有意义。如果我们的语言只使用StrictCase，到处都有一种风格和前缀，那会更好。

有很多糟糕的C代码，区分大小写并不能让它可读，你无法做任何事情。在不区分大小写的语言中，您可以在代码中强制执行好样式而无需重写库。 在尚未存在的StrictCase语言中，所有代码都具有不错的质量：）

Answer 22

我已经阅读了整个帖子。我必须相信那些报告在案例敏感性中发现价值的人从未用真正的高级语言编写（根据定义，它不区分大小写）。 K＆amp; R承认C是中等水平。在使用Pascal，Delphi，Lazarus，ADA等进行编程之后，人们了解到高度可读的代码编写起来很简单并且能够快速运行而无需考虑简洁的区分大小写的结构。毕竟，可读性是该主题的第一个也是最后一个词。代码是为人而不是计算机编写的。使用不区分大小写的代码调试没有问题。 当一个向下移动到中级语言时，人们会发现区分大小写没有任何优势。但是，在调试区分大小写时花费了相当多的时间来引起问题。特别是在将来自不同编码器的模块拼接在一起时。 似乎很多受访者都不理解不区分大小写的含义。只有字符a-z受到影响。这些是ASCII字符的连续子集。三到四个字节的机器代码使编译器对这个字符范围内的情况无动于衷。它不会改变欠条，数字或其他任何东西。关于其他语言和字符集的要点根本不适用于此讨论。编译器或中断器将被编码为在编译时基于ASCII是否临时转换或不转换字符以进行分析。

我很惊讶像Python这样的新语言重复了K＆amp; R所犯的错误。是的，他们在编译器，源和目标代码的总RAM为1000字节的环境中保存了半打字节。就在那时。现在记忆不是问题。现在，由于没有明智的原因，即使Python中的保留字也区分大小写！我不认为我需要使用＆＃34; For＆＃34; ＆＃34;打印＆＃34;作为变量或函数名称。但是，由于在每个标识符的确切情况下使用中断器花费了大量时间，因此保留了这种可能性。我认为这是一个糟糕的交易。

我迄今为止最接近支持区分大小写的内容是对Hashing的评论。但是这些罕见的编码事件可以通过仔细注意细节来处理，似乎不值得编码器必须使用来编写区分大小写的代码进行毫无意义的审查。两个问题的看法。一个人鼓励编码错误，在代码中设置陷阱，并需要额外注意从更大的概念转移。另一方没有缺点，在高级语言中完美无缺，并且在没有任何伤害的情况下允许灵活性。在我看来，还有另一个VHS胜过BETA的案例。这只是我的两分钱。

Answer 23

还有另一个原因是语言区分大小写。 ID可以存储在散列表中，散列表依赖于散列函数，散列函数将为不同的情况提供不同的散列。在通过散列函数运行之前，将所有ID转换为全部或全部更低可能并不方便。我在编写自己的编译器时遇到过这个问题。将我的语言声称为区分大小写更加简单（懒惰）。

Answer 24

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

但为什么你想要吗？

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

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

Answer 25

因为很多人发现employeeSocailSecurityNumber与employee_social_security_number一样可读，而且更短。

Answer 26

  

根据典型的编码标准，Person将是一个类，person是变量名，PERSON是常量。使用具有不同大小写的相同单词来表示相关但略有不同的内容通常很有用。

所以，如果你的公司里有三名工作人员都叫罗伯特，你会把他们称为罗伯特，罗伯特和罗伯特，不是吗？并依靠人们确切地知道你的意思？

如果您的电子邮件系统区分大小写，请提供电子邮件地址，例如Robert @ widgets.com，robert @ widgets.com和ROBERT@widgets.com？

未经授权违反个人数据的可能性很大。更不用说你是否将数据库root密码发送给即将被解雇的心怀不满的员工。

最好叫他们Bob，Robbie和Robert。更好的是，如果他们的姓氏是他们的姓氏，可以称他们为Robert A，Robert B和Robert C.亚瑟，班克斯和克拉克

真的 - 为什么在地球上有一个命名惯例会引起错误或混淆，这依赖于人们非常警觉？在你的volcabulary中你是否缺乏言语？

至于提到所谓的方便技巧“MyClass myClass”的人 - 为什么，为什么？您故意难以一目了然地看到使用的方法是类方法还是实例方法。

另外，你失去了告诉下一个阅读你的代码的人更多关于该课程的特定实例的机会。

例如。

客户PreviousCustomer

客户NewCustomer

客户CorporateCustomer

您的实例名称最好告诉您的同事，而不仅仅是它所基于的课程！

Answer 27

如果单词分离不重要那么为什么我们在单词之间放置空格？因此，我认为名称中的单词之间的下划线确实增加了可读性。使用适当字符大写的小写也是最容易阅读的。最后，如果所有的话都可以通过口头传播 - “企业下层客户”而不是“资本C小写情况下的下划线资本C小写情况”，那肯定会容易得多！ - 前者可以说“一个人的头脑”，后者不能 - 我想知道那些对案例敏感感到满意的人如何在他们的大脑中处理这些区分大小写的名字 - 我真的很挣扎。所以我认为区分大小写并不是一件有用的事情 - 在我看来，这是COBOL的一个倒退步骤。

Answer 28

看起来人们大多同意区分大小写是重要的，我同意。

但是，当你必须在正确的情况下键入内容时会很烦人，所以我认为IDE应该让你键入错误的情况，但是如果你点击自动完成的快捷方式，它应该进行不区分大小写的匹配。这给了我们两全其美。

Answer 29

因为人们认真地思考事物。

在不区分大小写并且与类型和变量名称空间之间的分离相结合的情况下，不区分大小写最有效。这意味着：

• 如果您将课程声明为＆＃39; TextureImage＆＃39;然后尝试将其用作＆＃39; textureImage＆＃39;，IDE可以自动更正您。这样，除非您重新声明标识符或使用下划线，否则您将永远不必点击Shift键。

• 就像Java和其他几种语言一样;键入＆＃34; MyClass myClass＆＃34;完全有效。 IDE和编译器在区分类型的使用和使用变量方面应该没有问题。

此外，不区分大小写可以保证＆＃39; o＆＃39;和＆＃39; O＆＃39;绝不会引用不同的对象。常见的论点包括：

• ＆＃34; sOmEoNe wIlL tYpE cOdE lIkE tHiS＆＃34 ;; =＆GT; 并且有人将被允许加入编程团队，所以这是一个稻草人的论点。即使他们确实设法这样做，不区分大小写更能解决问题，因为这意味着你不必记住他们使用的任何疯狂的大写/小写组合。

  < / LI>

• ＆＃34;您无法轻松地将案例不敏感国际化！＆＃34 ;; =＆GT; 超过95％的编程语言都是用英语编写的，这是有充分理由的。没有竞争性的字符编码，地球上的绝大多数键盘都是基于英语的（部分或全部）。支持unicode标识符可能是21世纪任何人都想到的最愚蠢的想法;因为unicode字符的很大一部分是frikkin不可见的surragates，阅读代码很难，而不必使用谷歌翻译，编写代码是很难的，无需复制粘贴标识符或使用字符映射。

• ＆＃34;但区分大小写的语言有更多标识符！＆＃34 ;; =＆GT; 不，他们有语法上重载的标识符，这实际上更糟糕。

我没有使用任何不区分大小写的语言，但如果你认真考虑这类事情，那么优势就显而易见了。

Answer 30

合理的答案可能是该语言的设计者认为它 会让语言更容易理解未来：）

Answer 31

  

MyClass myClass;   用不区分大小写的编译器是不可能的。

或者你可能很聪明，实际上使用了2个不同的单词......更好地展示了你实际上想做的事情，比如：

  

MyClass myCarDesign;

咄。