低驼峰案例变量套管约定（例如thisVariable）有什么意义？

Question

我希望由于过于宽泛而无法关闭。我知道这取决于个人偏好，但是所有套管惯例都有起源，我想知道这个来自哪里，以及人们使用它的原因的合理解释。

这就是你var empName;所有的地方。我称之为较低的骆驼，虽然它可能在技术上被称为其他东西。就个人而言，我像var EmpName一样。我称之为正确的骆驼，我喜欢它。

当我第一次开始编程时，我开始使用较低的骆驼惯例。我不知道为什么。我只是按照所有老家伙的例子来做。变量和函数（VB）得到了较低的骆驼，而潜艇和属性得到了适当的骆驼。然后，在我最终掌握了编程本身之后，我变得足够自在地质疑我的导师的策略。使用较低的骆驼对我来说没有道理意义，因为它不一致，特别是如果你有一个由一个单词组成的变量，最后都是小写的。也没有确定你正确使用低骆驼和高骆驼的验证机制，所以我问为什么不只是使用适当的骆驼来做所有事情。它是一致的，因为所有变量名都受到适当的骆驼化。

深入挖掘它后，事实证明，当它受到质疑时，这对许多程序员来说是一个非常敏感的问题。他们通常回答：“嗯，这只是个人偏好”或“这就是我学习它的方式”。在进一步刺激时，它通常会引起与人的一种教条反应，因为我试图找到使用低骆驼背后的逻辑原因。

所以，任何人都想在适当的白化品种的背后留下一点历史和逻辑吗？

Answer 1

这是两件事的组合：

• 以小写字母开头的变量约定，以区分使用大写的类或其他实体。这有时也用于区分访问级别（私人/公共）
• CamelCasing是一种让多词名称更具可读性而无空格的方法（当然这是对下划线的偏好，有些人会使用）。我猜测逻辑是CamelCasing对某些人来说比word_underscores更容易/更快。

它是否被使用当然取决于设置管理正在编写的代码的编码标准的人。下划线与CamelCase，小写变量vs大写变量。 CamelCase + lowercasevariable = camelCase

Answer 2

在C＃或VB等语言中，标准是使用小写启动私有内容并使用大写启动公共/受保护的东西。通过这种方式，只需查看第一个字母就可以判断出您正在弄乱的东西是否可以被其他类使用，因此任何更改都需要更多的审查。此外，还有 工具来强制执行这样的命名约定。在Microsoft内部创建/使用的名为StyleCop，可以免费下载。

Answer 3

历史上，C语言（一个区分大小写的语言）中命名良好的变量由小写的单个单词组成。大写是为宏保留的。

然后是C ++，其中类通常是CapitalizedAndCamelCased，而由几个单词组成的变量/函数是camelCased。 （请注意，C人倾向于不喜欢camelCase，而是编写identifier_this_way。

从那里开始传播。

而且，是的，可能其他区分大小写的语言也有一些影响。