语言不区分大小写的关键字[关闭]

我们正在尝试编写自定义脚本语言。有人建议通过提供不区分大小写的关键字来使语言宽容。

我个人不喜欢这个主意，但是我的团队中很少有人倾向于这个主意，说它将使最终用户满意！给出了诸如FORTRAN，BASIC，SQL之类的语言示例，称它们不区分大小写。

这是一个好主意吗？

问问自己最终用户是谁。如果要由具有C或Javscript编程经验或Unix的IT经验的人编写，那么区分大小写可能是正确的选择，因为这是用户的期望。但是对于大多数最终用户，甚至是高级用户，这将造成混乱。

VB / VBA / VBScript不区分大小写，这是为了使非程序员可以轻松掌握该语言的决定。Excel公式（不完全是脚本，而是尽可能多的用户）不区分大小写。在大多数写作中，大小写的选择可以使文本看起来或多或少显得专业和优美，但大小写本身不会改变单词的语义。这就是为什么我认为非开发人员会对区分大小写的脚本语言感到困惑。

同样，这不是技术选择。这是产品管理的选择，必须由对目标受众非常了解的人员做出。

您应该根据想要呈现的用户体验来决定，而不是要实现起来多么容易或困难。

如果这将使您的用户更容易实现不区分大小写的功能，那么这就是您应该实现的。

举例来说，SQL不区分大小写。这使得在交互式设置中非常容易使用。

看看这另一种方式是-还能有之间的差异keyword和Keyword你的语言，并将这种差异是对用户有意义？对于脚本语言，我会说答案是“否”。

编程语言应区分大小写。人们可以很容易地对此进行调整：他们只需要记住大部分工作都使用小写字母，并且要注意现有API中的大小写混合或全大写的标识符。

曾经使语言不区分大小写似乎是显而易见的。这是因为小写字母并非在所有计算系统及其I / O设备（键盘，打印机和显示设备）上都可用。编程语言实现必须接受以大写形式编写的程序，因为只有这样才能显示或打印。为此，它们必须不区分大小写，因为接受大写并同时区分大小写意味着拒绝小写。小写是程序员想要的，但并非总是如此。没有人真正想使用大写的程序。这只是硬件限制。

有一阵子，甚至在终端上折叠箱子也是很普遍的。如果终端只能显示大写字母，但是您必须登录到支持大写和小写字母的计算系统，则终端会将小写字母折叠为大写字母。认为这是很久以前的事了吗？“与Apple II一样，Apple II Plus也没有小写功能。” （http://zh.wikipedia.org/wiki/Apple_II_Plus）当早期Apple计算机的用户拨入包含大小写混合的BBS时，终端仿真器（或主机）必须将其全部折叠为大写。当时，所有大写字母的消息在公告板上都很常见。在类似Unix的操作系统（如Linux内核）中仍然可以找到此功能。例如，键入stty olcuc在shell提示符下。Unix tty行规程可以将小写字母映射到输出的大写，也可以将大写字母映射到输入的小写。这使您可以在没有小写字母的终端上以小写字母的编程语言进行工作。

不区分大小写是过去的计算机时代的过时概念，在现代国际化计算世界中效果不佳。您是否将其扩展到其他语言？法语呢：您认为È和è等效吗？还是日语？您是否认为平假名和片假名只是案例，以便ファイル和ふぁいる是相同的标识符？对这种愚蠢的支持将使您的词法分析器大大复杂化，后者必须具有整个Unicode空间的大小写对等映射。

请注意，数学区分大小写。例如，大写的sigma可能表示求和，而小写的sigma则表示其他东西，例如标准差。这可以在相同的公式中发生而不会造成任何困难。（编程语言会使Σ和σ等效吗？）

英语拼字法很敏感。例如，许多专有名词对应于普通名词甚至其他词性。“ may”是动词，但“ May”是一个月或女人的名字。而且，如果首字母缩写词或缩写词用小写写，可能会造成混淆。SAT代表学业能力测验，而“ sat”是“ sit”的过去分词。聪明的人会注意细节并适当利用资本。

基本上，自1985年以来创建的任何不区分大小写的新编程语言都适用于那些仍然在电子邮件和帖子中大声疾呼而又没有第二次思考的人。

如果您的语言曾经被用作代码生成目标来翻译另一种语言的代码，并且该另一种语言区分大小写怎么办？您将必须以某种方式转换所有名称以捕获区别。（因此断言这不是技术决定，而仅取决于目标受众的情感偏好是可笑的。）

当文件从另一个操作系统导入时，请查看由Windows中的案例处理引起的烦人问题。那是一个技术问题。区分大小写的文件系统的外部数据有问题，不区分大小写的文件系统没有。

Common Lisp碰到了一种理想的方法：符号名区分大小写，但是当读取令牌时，它们会折叠为大写。这意味着令牌foo，fOO，FOO并且Foo都表示同一符号：他的名字被存储为字符串的符号"FOO"。此外，此行为只是默认的读取表配置。读者可以将字母折叠为大写，小写，反转大小写或保存。最后两个选择引起区分大小写的方言。这样，用户将具有最大的灵活性。

真正的决定性因素是您要多久使用同一个名称拥有多个事物。不区分大小写在SQL中起作用，因为您通常不希望使用名为的列SELECT。在Java中这会很烦人，因为每隔一行看起来像Object object = new Object()，您希望在其中相同的名称引用一个类，一个实例和一个构造函数。

换句话说，区分大小写对于重载名称最有用，而在大型，复杂的项目中重载最有用。对于不经常使用的语言（例如脚本语言），不区分大小写可使编程更加简单。

我曾经做过一种规则语言，其中标识符不仅不区分大小写，而且不区分空格。我还允许创建引用相同标识符的别名。例如，ProgrammersStackExchange，程序员堆栈交换和PSE都解析为完全相同的符号，可以互换使用。

对于我的域名来说，这很好用，因为域名有很多非常著名的方式来引用同一件事，而且命名冲突很少见。使用一个名称键入查询并使用另一个名称查询结果，不会令任何人感到惊讶。语言支持使域和编程语言之间的转换非常容易。但是，这也使某些任务更加困难，例如查找对变量的所有引用。幸运的是，在我的情况下，这种情况很少出现，或者很容易建立工具支持来提供帮助，但是您必须考虑到自己的情况。

假设您的脚本语言区分大小写-您是否要创建一个编译器或语法检查器，以告诉用户是否在变量名或关键字中使用了错误的大小写，从而造成了拼写错误？如果不是，那将是使该语言不区分大小写的一个非常有力的论据。

您可以即时声明变量吗？如果是这样，我会反对区分大小写，因为跟踪由

ATypo = 42; 

相对于

Atypo = 42; 

当两个语句相等时，将不必要地要求调试时间，这会使生活更轻松。

给出了诸如FORTRAN，BASIC，SQL之类的语言示例，称它们不区分大小写。

FORTRAN和SQL（和COBOL）不区分大小写的原因是，它们最初是为在普通字符集只有大写字母的计算机上使用而设计的。至少（至少）这些语言中的不区分大小写是一种历史的手工艺品，而不是一种语言设计选择。

现在您可以辩称，对大小写的不敏感性会更宽容，但另一方面，因为对大小写的敏感度是由用户选择的，因此可以使代码更具可读性。

区分大小写被认为是有害的。

生活不区分大小写，用户或程序员也不一样。

区分大小写的语言是历史悠久的事故，是受约束的系统的结果，这些系统发现不区分大小写的比较比较困难。这种障碍不再存在，因此没有理由再次使区分大小写的计算机系统成为现实。

我什至可以说区分大小写是有害的，因为它使计算机的便利性高于用户的便利性。

（相关，我记得几年前，一些天才因为他的名字大写而拒绝支付他的信用卡账单，但是他拼写错了。）有效的付款要求。法官应理所当然地对待该论点。

从我的个人经验来看，区分大小写和不区分大小写的语言之间并没有太大区别。

更为重要的是命名和结构约定，程序员应该保留在其代码中，并且没有编译器或解析器为他检查它。如果您遵循某种规则，您将很容易知道一个专有名称（您不会认为您是否将变量命名为checkOut或CheckOut），并且您的代码可能区分大小写并且更易于阅读。

不应以相同的含义使用CheckOut和checkOut和checkout以及cHeCkOuT和CHECKOUT。这会损害可读性，并使对这种代码的理解更加痛苦（但是，有一种更糟糕的事情，那就是破坏代码的可读性）。

如果您使用某种规则，例如，您将一目了然：

CheckOut.getInstance（）-它是称为checkOut.calculate（）的类的静态方法-它是将对象保留在名为_checkOut.calculate（）的变量或公共字段中的方法-它是将对象保留在称为CHECKOUT的私有字段中的方法-这是最终的静态或常量字段/变量

而不签出其他文件或文件的某些部分。它使读取代码更快。

我看到许多开发人员使用类似的规则-用我经常使用的语言：Java，PHP，动作脚本，JavaScript，C ++。

在极少数情况下，可能会对不区分大小写的内容感到生气-例如，当要使用CheckOut作为类名，而想使用checkOut作为变量，而又因为它们相互冲突而无法使用时。但这是程序员习惯于区分大小写并在其命名约定中使用它的问题。可以使用不区分大小写的语言使用带有标准前缀或后缀的规则（我不使用VB编程，但我知道许多VB程序员都具有这种命名约定）。

简而言之：我认为区分大小写更好（仅适用于面向对象的语言），因为大多数开发人员都使用区分大小写的语言，而且大多数开发人员都基于区分大小写使用命名约定，因此他们希望更好的语言是区分大小写的，因此能够坚持自己的规则而无需进行任何修改。但这是相当宗教性的论点-不是客观的论点（不是基于实际的缺点或区分大小写的好方面-因为当涉及到bAd DeVeLoPeR时，对于优秀的开发人员，我看不到任何东西，可能会产生噩梦般的代码即使区分大小写，也没有太大区别）。

编程语言应不区分大小写。

如今，如此之多的语言区分大小写的主要原因仅仅是出于对货物习惯的语言设计：“ C就是这样做的，而C非常受欢迎，所以它一定是正确的。” 和其他很多事情一样，C证明了这一错误。

这实际上是C和UNIX背后的驱动原理的一部分：如果您在易于实施的不良解决方案与难以实施的良好解决方案之间做出选择，请选择不良解决方案，并将解决混乱的负担推到另一边。用户。 这听起来像蛇，但绝对是真的。它被称为“更糟糕的原则”，在过去的几十年中，由于C和C ++，它直接造成了数十亿美元的损失，这使得编写故障和不安全的软件变得太容易了。

使语言不区分大小写肯定更容易；您不需要词法分析器，解析器和符号表就不必执行额外的工作来确保所有内容都以不区分大小写的方式匹配。但这也是一个坏主意，原因有二：

• 首先，尤其是在构建脚本语言时，这是一个简单的错字，其中一个地方称为“ myObject”，另一个地方称为“ MyObject”，您显然是在指相同的对象，但与大小写有点不一致，不会变成运行时错误。（这是臭名昭著的错误脚本语言的主要痛点，例如Python。）
• 其次，不区分大小写意味着仅通过更改大小写就不能滥用区分大小写，使同一个单词在相同范围内引用两个不同的事物。如果您曾经不得不在C环境中使用Windows代码，并遇到诸如的丑陋声明HWND hwnd;，那么您将确切地知道我在说什么。这样写的人应该被带走并开枪，并且使语言不区分大小写可防止区分大小写滥用进入您的代码。

因此，请付出额外的努力使其正确。生成的代码将更干净，更易于阅读，更少的错误，并使您的用户更加高效，这不是任何编程语言的最终目标吗？

我不敢相信有人说“区分大小写使阅读代码更容易”。

它肯定不是！我在同事的肩膀上看着名为Company和company（公共变量Company，相匹配的私有变量company）的变量，他对字体和颜色的选择使得很难分辨两者之间的区别，即使彼此相邻也是如此。

正确的语句应为“大小写混合使阅读代码更容易”。这是一个更为明显的事实-例如，名为CompanyName和CompanyAddress而不是companyname的变量。但是我所知没有一种语言使您只能使用小写的变量名。

我所知道的最疯狂的约定是“大写公共，小写私有”。只是自找麻烦！

我对错误的看法是“更好的是，某些事情会吵闹且尽快，而不是悄然失败，但看起来会成功”。而且没有比编译时间要早的了。

如果在使用大写字母时错误地使用了小写字母变量，则在同一类中引用它时，该变量通常会编译。因此，您似乎可以在编译和运行时均获得成功，但会巧妙地做错事，并且可能很长一段时间都没有发现它。当您确实发现有问题时

最好使用私有变量具有后缀的约定-例如，公司公共变量，公司P私有变量。没有人会意外地将两者混为一谈，并且它们在智能感知中一起出现。

这与人们对匈牙利表示法的异议形成了鲜明对比，匈牙利表示法的前缀是私有变量pCompany不会出现在intellisesne中的合适位置。

该约定具有可怕的大写/小写约定的所有优点，而没有缺点。

我认为人们感到需要区分大小写以区分变量，这一事实表明我既缺乏想象力，也缺乏常识。或者，可悲的是，人类的绵羊喜欢遵循约定的习惯，因为“这就是它总是会完成的方式”

即使彼此相关，也要使您使用的事物彼此之间明显且明显地不同！

没有充分理由不应该不区分大小写。例如，使用Unicode处理大小写比较可能很麻烦。较旧语言的区分大小写（或缺乏区分大小写）并不重要，因为它们的需求差异很大。

这个时代的程序员期望区分大小写。

区分大小写使代码更具可读性，并使编程更容易。

• 人们发现正确使用混合大小写更容易阅读。

• 它允许/鼓励CamelCase使得相同的单词具有不同的大小写可以引用相关的事物：Car car; 因此，car创建了名为type 的变量Car。

• ALL_CAPS_WITH_UNDERSCORES通过多种语言约定表示常量

• all_lower_with_underscores可以用于成员变量或其他。

• 所有现代编程工具（源代码控制，编辑器，diff，grep等）均专为区分大小写而设计。如果您使用不区分大小写的语言，那么您将永远遇到程序员认为理所当然的工具的问题。

• 如果将解释语言，则对代码的大小写不敏感的解析可能会降低性能。

• 非英文字符呢？您是否现在决定不再支持科普特语，汉语和北印度语？我强烈建议您将语言默认设置为UTF-8，并且支持某些语言不包含大写或小写字母的语言。您不会在关键字中使用这些字符，但是当您开始在各种工具中关闭区分大小写（例如，在文件中查找内容）时，您会遇到一些超现实且可能令人不快的体验。

有什么好处？您提到的3种语言是1970或更早的版本。没有现代语言可以做到这一点。

另一方面，任何使最终用户满意的事物都会给世界带来一点光明。如果它确实会影响用户的满意度，那么您就必须这样做。

如果您想让最终用户真正简单，可以做得比区分大小写/不区分大小写更好-请看一下Scratch！减少了卡通猫的数量，增加了对企业友好的颜色，并且您拥有我所见过的最友好的语言-而且您无需编写任何东西！只是一个想法。