46

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

仅仅是继承的问题吗？C++ 是区分大小写的，因为 C 是，Java 是区分大小写的，因为 C++ 是，等等？还是背后有更务实的原因？

4

31 回答 31

66

我认为您不会得到比“因为该语言的作者认为那样更好”更好的答案。就个人而言，我认为他们是对的。我不想在同一个源文件中的任何地方找到这些行（并引用同一个对象+方法）......

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

我想没有人会高兴看到这个...

于 2009-02-02T13:34:35.147 回答
64

Unix。

Unix 是区分大小写的，因此为在 Unix 上使用而开发的许多编程语言都区分大小写。

计算机不会宽容-大写字符与小写字符不同，它们完全不同。而在处理周期、RAM 等很昂贵的时候，强迫编译器和计算机“宽容”的努力并不值得，人们只是想让这些东西正常工作。

请注意，在Visual Basic出现之前，不区分大小写并没有真正成为有用的东西——一旦公司开始投资于让大众编程对他们的底线是一件好事的概念（即，微软赚更多的钱，如果Windows 上有更多程序）语言是否开始变得更友好和更宽容。

于 2009-02-02T15:19:12.660 回答
36

要考虑的一件有趣的事情是英语也区分大小写。（我怀疑这对大多数自然语言都是正确的，但可能并非对所有人都是正确的。）

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

我喜欢读书。

和

我喜欢读书。

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

编程语言区分大小写的一个明显优势是文本也变得不区分文化。不得不偶尔向编译器说明源文件使用哪种文本编码已经够糟糕了——必须指定它所在的文化会更糟:(

于 2009-02-02T13:40:49.627 回答
28

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

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

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

于 2009-02-02T13:35:40.637 回答
24

我的猜测是区分大小写会扩大名称空间。一个不错的技巧，例如

MyClass myClass;

使用不区分大小写的编译器是不可能的。

于 2009-02-02T13:35:19.343 回答
24

大小写折叠仅在英语中很简单（并且对于所有字符 < 128）。德语sz 或 "sharp s" (ß)在 ISO 8859-1 字符集中没有大写变体。经过大约十年的讨论，它只收到了一个 Unicode 格式（现在，所有字体都必须更新......）。汉字和平假名（日语字母）甚至不知道小写。

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

于 2009-02-02T13:43:39.433 回答
15

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

一旦出现仅通过其案例唯一的标识符，就很难再返回了。许多开发人员喜欢它，并且似乎并没有很大的意愿撤消它。

于 2009-02-02T13:35:25.583 回答
15

ExpertSexChange

我相信这是 Stack Overflow 的竞争对手，您必须付费才能阅读答案。嗯...不区分大小写，站点名称的含义是模棱两可的。

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

于 2009-02-14T19:03:46.247 回答
11

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

Person person = new Person("Bill");

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

此外，如果让 Person、person、Person、PersoN、PersOn 和 PERSON 都是等价的标记，我会很头疼。:)

于 2009-02-02T13:40:30.377 回答
9

i的大写形式是什么？我（U+0049）还是我（U+ 0130）？

大小写取决于语言环境。

于 2009-02-02T15:58:15.840 回答
8

因为他们像一盒青蛙一样愚蠢，正是因为在这个线程中给出了相反观点的原因（我什至不会问那是什么。木头换树等等）。

当 FOOBAR = FooBar = foobar 时，您可以选择您的约定，其他编码人员也可以这样做，无论他们是否同意您的偏好。没有混乱。

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

你调用你的变量网站，他们调用他们的网站，哪个系统会混淆？扫描时也不是一件容易的事。

至于查找，在查找之前将名称转换为小写真的需要更多处理吗？进行自己的过早优化是一回事，期望从您选择的语言的开发人员那里得到它是完全不同的层次。

...然而，所有这些说区分大小写的答案减少了混淆。叹

于 2009-02-02T15:12:02.890 回答
8

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

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

主张区分大小写语言的人一定无法区分

IAmNowHere

从

IAmNowhere

（这是个玩笑！ ;-)

于 2009-02-02T15:13:41.297 回答
4

如果你没有帽子，你怎么大喊大叫？！啊！

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

于 2009-02-02T13:48:32.000 回答
4

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

（Franz Lisp 一度引入了他们所谓的“现代”大写，其中 Listener 不会折叠大小写，而 CL 关键字将小写。我从来没有很好地遵循它，以至于不知道那里发生了什么。）

于 2009-02-02T15:31:06.130 回答
4

字母的大写不是一个通用的概念。Java 使用 Unicode，因此如果您想要不区分大小写的 Java，程序的含义可能会根据编译的语言环境而改变。

大多数语言不允许您将点或逗号（或撇号或空格）放在整数文字的中间，可能是因为这也取决于语言环境。

于 2009-02-02T18:31:34.173 回答
4

来自 .NET Framework Developer's Guide Capitalization Conventions，区分大小写：

大写指南的存在只是为了使标识符更易于阅读和识别。大小写不能用作避免库元素之间名称冲突的方法。

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

于 2009-02-14T18:31:25.030 回答
4

我已经阅读了整个线程。我必须相信那些报告发现区分大小写的价值的人从未使用真正的高级语言（根据定义不区分大小写）进行编程。K&R 承认 C 是中等水平。在使用 Pascal、Delphi、Lazarus、ADA 等进行编程后，人们了解到高度可读的代码很容易编写并且可以快速运行，而不必拘泥于简洁的区分大小写的结构。毕竟，可读性是关于这个主题的第一个也是最后一个词。代码是为人编写的，而不是为计算机编写的。使用不区分大小写的代码进行调试没有问题。当一个人转向一种中级语言时，会发现区分大小写没有任何优势。然而，调试区分大小写所花费的大量时间会导致问题。尤其是在将来自不同编码器的模块拼凑在一起时。似乎还有很多受访者不理解不区分大小写的含义。只有字符 az 受到影响。这些是 ASCII 字符的顺序子集。三个或四个字节的机器代码使编译器在这个字符范围内对大小写不感兴趣。它不会改变下划线、数字或其他任何内容。关于其他语言和字符集的要点根本不适用于此讨论。编译器或中断器将被编码为临时转换或不转换字符以在编译时根据是否为 ​​ASCII 进行分析。这些是 ASCII 字符的顺序子集。三个或四个字节的机器代码使编译器在这个字符范围内对大小写不感兴趣。它不会改变下划线、数字或其他任何内容。关于其他语言和字符集的要点根本不适用于此讨论。编译器或中断器将被编码为临时转换或不转换字符以在编译时根据是否为 ​​ASCII 进行分析。这些是 ASCII 字符的顺序子集。三个或四个字节的机器代码使编译器在这个字符范围内对大小写不感兴趣。它不会改变下划线、数字或其他任何内容。关于其他语言和字符集的要点根本不适用于此讨论。编译器或中断器将被编码为临时转换或不转换字符以在编译时根据是否为 ​​ASCII 进行分析。

我对像 Python 这样的新语言重复了 K&R 所犯的错误感到震惊。是的，他们在编译器、源代码和目标代码的总 RAM 为 1000 字节的环境中节省了 6 个字节。那时就是这样。现在内存不是问题。现在，莫名其妙地，即使是 Python 中的保留字也是区分大小写的！我认为我不需要使用“Print”的“For”作为变量或函数名。但是这种可能性已经被保留下来，因为在每个标识符的确切情况下满足中断器所花费的时间是昂贵的。我认为这是一笔糟糕的交易。

迄今为止，我读过的支持区分大小写的最接近的内容是关于 Hashing 的评论。但是，这些罕见的编码事件可以通过仔细注意细节来处理，但似乎不值得编码人员在编写区分大小写的代码时进行毫无意义的审查。对问题的两种看法。一种是鼓励糟糕的编码，在代码中设置陷阱，并且需要额外的注意力才能转移到更大的概念上。另一个没有缺点，在高级语言中完美地工作，并且在没有害处的情况下允许灵活性。在我看来，这就像 VHS 战胜 BETA 的又一案例。这只是我的两分钱在这里。

于 2015-12-08T22:34:55.727 回答
3

这里的很多人都说过，用几种形式的大写来指代同一个东西是不好的，例如：

person
perSoN
PERSON

真正糟糕的是，如果这些都在代码中引用了不同的对象。如果你有变量 person、perSoN 和 PERSON 都指不同的东西，那么你就有问题了。

于 2009-02-02T14:02:38.587 回答
3

区分大小写并不能真正帮助大小写一致性。 

Foo.Bar  
foo.Bar  
fOO.bAR

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

于 2009-02-02T14:09:00.303 回答
3

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

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

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

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

于 2009-04-22T07:28:12.620 回答
3

我看到的每个支持区分大小写的示例都是基于编写糟糕的、无法描述的代码的愿望。例如“日期”与“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 代码中是完全有效的情况。区分大小写允许您甚至更公然违反良好的编程习惯的想法是反对它的论据，而不是支持它。

于 2009-12-23T17:19:16.170 回答
1

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

于 2009-02-02T14:16:24.797 回答
1

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

但是你为什么想要？

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

function a(a)
{
    int a = a.a;
    return a
}
于 2009-04-24T04:51:32.483 回答
1

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

因此，如果您的企业中有 3 名员工都叫 Robert，您会称他们为 Robert、robert 和 ROBERT，对吗？并依靠人们确切地知道您的意思是哪一个？

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

未经授权的个人数据泄露的可能性将是巨大的。更不用说您是否将数据库根密码发送给即将被解雇的心怀不满的员工。

最好叫他们鲍勃、罗比和罗伯特。如果他们的姓氏是 Arthur、Banks 和 Clarke，最好还是称他们为 Robert A、Robert B 和 Robert C

真的 - 为什么会有一个会引起错误或混淆的命名约定，这依赖于人们非常警觉？你的词汇量这么少吗？

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

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

例如。

上一个客户

客户新客户

客户公司客户

理想情况下，您的实例名称需要告诉您的同事，而不仅仅是它所基于的类！

于 2014-04-04T14:45:25.597 回答
1

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

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

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

区分大小写和不区分大小写的语言都需要严格的纪律，到处只有一种风格更有意义。如果我们有一种只使用 StrictCase、一种风格和前缀的语言，那就更好了。

有很多糟糕的 C 代码，区分大小写不会使其可读，您对此无能为力。在不区分大小写的语言中，您可以在代码中强制使用良好的样式，而无需重写库。在尚不存在的 StrictCase 语言中，所有代码都将具有良好的质量:)

于 2016-04-27T21:40:10.613 回答
0

我的班级我的班级；使用不区分大小写的编译器是不可能的。

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

我的类我的汽车设计；

呃。

于 2009-04-22T07:30:50.240 回答
0

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

于 2014-03-02T12:34:40.120 回答
0

如果单词分隔不重要，那么我们为什么要在单词之间放置空格？因此，我认为名称中单词之间的下划线确实会增加可读性。此外，适当字符大写的小写字母最容易阅读。最后，如果所有的词都可以通过口耳相传来传达，那肯定会容易得多——“Corporate Underscore Customer”而不是“Capital C Lower Case orporate Underscore Capital C Lower Case ustome r”！- 前者可以“在脑海中”说出后者不能 - 我想知道那些对区分大小写感到满意的人如何在他们的大脑中处理这些区分大小写的名称 - 我真的很挣扎。所以我觉得区分大小写根本没有帮助——在我看来，这是 COBOL 的倒退。

于 2015-10-15T10:02:29.330 回答
0

因为人们严重地想太多事情。

不区分大小写在保留大小写并结合类型和变量命名空间之间的分离时效果最佳。这意味着：

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

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

此外，不区分大小写保证 ' o' 和 ' O' 永远不会引用不同的对象。常见的论点包括：

  • " sOmEoNe wIlL tYpE cOdE lIkE tHiS"; =>并且有人_永远不会_被允许加入编程团队，所以这是一个稻草人的论点。即使他们确实做到了，不区分大小写更多的是解决问题而不是问题，因为这意味着您不必记住他们使用的任何疯狂的大写/小写组合。

  • “你不能轻易国际化不区分大小写！”; =>超过 95% 的编程语言是用英语编写的，这是有充分理由的。没有竞争的字符编码，地球上绝大多数键盘都是基于英语的（部分或全部）。支持 unicode 标识符可能是 21 世纪任何人想出的最愚蠢的想法；因为很大一部分 unicode 字符是 frikkin 不可见的代理，所以无需使用谷歌翻译即可阅读代码，无需复制粘贴标识符或使用字符映射即可编写代码。

  • “但区分大小写的语言有更多标识符！”；=>不，它们有语法重载的标识符，这实际上更糟。

我不使用任何不区分大小写的语言，但是如果您认真考虑这类事情，其优势是显而易见的。

于 2017-01-15T14:05:45.090 回答
0

一个合理的答案可能是该语言的设计者认为这将使该语言更容易理解并考虑未来:)

于 2017-07-28T00:35:01.393 回答
-1

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

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

于 2009-02-02T17:23:44.687 回答