在局部变量（例如，employeeCount，firstName）中的第一个单词使用小写的原因是什么？

由于我对所有变量都使用了完全正确的大小写形式，因此引起了其他程序员的大量批评。例如，您的典型程序员将使用employeeCount变量名，但我使用EmployeeCount。我对所有内容都使用完全正确的大小写，无论是void方法，return方法，变量，属性还是常量。我什至在Javascript中都遵循此约定。最后一个确实震撼了人们的傻瓜。

关于为什么我不应该遵循这种“非标准”大写字母约定的典型原因是，应为属性和void方法保留完整的适当大小写。局部变量和返回值的方法的首字母应小写，例如int employeeCount = getEmployeeCount()。

但是，我不明白为什么。

当我对此提出疑问时，似乎只能得到一个任意的答案，那就是标准。不管答案是什么，它通常总是归结为这就是它的样子，我对此并不怀疑。我只是跟随它。。任意答案对我来说永远不够好。

自从使用Office IDE对Excel 97宏进行编程的早期开始，我就不需要用大小写约定来告诉我某些东西是局部变量还是属性。这是因为我一直使用非常直观的命名约定。例如，GetNuggetCount()很明显地提出了一种方法，该方法可以计算所有矿块的数量。 SetNuggetCount(x)建议您为块数分配一个新值。 NuggetCount所有这些本身都暗示了仅包含值的属性或局部变量。对于最后一个，可能会想说：“啊哈！这是问题。属性或变量？这是什么？” 为此，我会回答：“这真的重要吗？”

因此，这就是tl; dr ;：在变量或return方法中的第一个单词使用小写字母的客观，逻辑，非任意原因是什么？

编辑： 对于MainMa

将此代码替换为答案中的第一个代码示例，然后查看您的论点是否成立：

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

当人们希望为变量赋予与变量名称相同的名称时，通常使用该命名约定。例如：

Employee employee;

有些语言甚至强制使用大写字母。不必使用恼人的变量名像这样可以防止MyEmployee，CurrentEmployee，EmployeeVar等你总是可以告诉我们，如果事情是一个类型或一个变量，仅仅从资本。这样可以避免在以下情况下造成混淆：

employee.function(); // instance method
Employee.function(); // static method

另外，在英语中，名词通常不大写，因此您不能真正声称自己的大写是“正确的”。

那与您的情况有什么关系？显然，阅读自己的代码没有问题，但是通过保持尽可能一致，可以减少其他需要阅读代码的人的工作量。以书面形式编码时，您可以调整样式以适合读者。

没有 这是大多数人的工作，因此它已成为标准，因为这就是每个人的工作。许多文献都遵循这一惯例，所以人们逐渐习惯了。

约定不如整个代码的一致性那么重要。只要以一致的方式命名所有内容，以便我可以通过查看它们来分辨出什么，首字母是否大写并不重要。

我发现遇到碰到以您的方式编写的代码会感到不高兴，并说我不喜欢它。但这是风格问题。

现在，如果您在工作场所中这样做，最好以团队风格进行编码，以使代码在任何地方都保持一致。而不是让您的代码与其他所有人不同。

http://thecodelesscode.com/case/9​​4

1.为什么存在该标准？

毕竟，让每个人都根据个人喜好编写代码，而不再谈论哪种标准更好是不是更好？

事实是，当您习惯一种样式时，阅读使用另一种样式的代码会更加困难。您的大脑会花更多的时间来尝试理解约定（如果有），而不是去理解代码的作用。

这两段代码之间更有可读性吗？

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

要么：

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

这两段代码执行相似。唯一的区别是，在第一种情况下，每个从事该项目的开发人员都使用自己的样式。这使代码不一致，难以阅读且危险。团队成员无法就缩进量达成一致的事实，再加上其中一个人拒绝在每次缩进之后使用花括号这一事实if使代码极易出错：纵观它，我们可能认为第二个if是仅当第一个if为真时才执行，情况并非如此。

在第二种情况下，所有开发人员都遵循相同的标准。其中一些人可能不满意，因为他们更喜欢两个空格的缩进，或者因为它们习惯于以小写字母开头的方法。事实是，这种方式的代码可读性仍然更高，并且如果他们使用任何其他标准，代码仍然会如此。

通过具有严格的统一标准，它使代码更易于阅读。

2.为什么它们的标准比我现在发明的标准要好？

如果世界各地成千上万的开发人员都在使用标准，那就坚持下去。不要自己发明：即使更好，也可以让您更轻松地迁移到全球标准，而不是迁移到成千上万的开发人员那里开始使用您的标准。

示例：在我自己的公司中，我有一个特定的约定来命名数据库中的主键和外键以及索引。这些名称看起来像：

• [FK for Application: CreatedByApplicationId]，
• [IX for SessionIPAddress: SessionId] 要么
• [PK for RoleOfPassword: RoleId, PasswordId]。

就我个人而言，我认为这项约定非常出色并且非常明确。为了我。但这完全糟透了。它很烂，因为它是我的，并且因为成千上万的数据库管理员从未使用过它。这意味着：

• 当我雇用DBA时，他将被迫学习新的惯例，而不是立即开始工作，

• 我无法按原样在互联网上共享代码：那些看起来很奇怪的名字会打乱那些会阅读我的代码的人，

• 如果我从外部获取代码以便自己使用，那么我将不得不修改名称以使其统一，

• 如果有一天我决定使用一些众所周知的标准，我将被迫去修改几百个名字中的每一个。

3.那么，大写呢？

与字段或局部变量相比，属性具有更大的范围或可见性。使属性以大写字母开头，然后将字段和变量（一小部分）朝这个方向发展。

如果考虑使用C＃，则此逻辑足够一致。

如果考虑使用Java，则方法以小写字母开头，这不符合逻辑。

因此，没有，没有确切的证据证明该约定比您的约定更好。只是全局使用了一个，而您却没有使用。没有比这更好的了。

在JavaScript中，函数以小写字母开头，除非它们new之前需要一个。否则会更好吗？也许。事实是，多年来，JavaScript开发人员一直使用此标准，而事实并非相反。现在重写每本书并强迫每个开发人员更改样式会有些复杂。

从技术上讲，这并不重要（或者至少在大多数语言中都没有关系）。

但是，大多数编程社区（无论是围绕一种特定语言形成的世界范围的社区，此类社区的子组，围绕某些流行的库或工具包而形成的组，还是仅单个团队）都已建立了已建立的编码标准。确切的细节是相对不重要的（虽然在很多情况下，一个很好的理由可以为他们制造），什么是重要的是你坚持给他们。

不是因为它们是最好的，而是因为它们是其他所有人使用的；如果您遵守该标准，则您的代码将与最终将要使用的其他大多数代码保持一致-库，队友代码，内置语言。一致的命名是一种强大的生产力武器，因为这意味着当您猜测某物的名称时，通常会猜对。难道file.SaveTo()，File.saveTo()，file.save_to()，FILE.save_to()？命名约定将告诉您。

将您的个人喜好带入您遇到的每种语言中尤其危险，因为首先，每种语言都有其自己的文化，并且命名约定通常是不兼容的。其次，就命名而言，语言之间存在许多细微的差异。

只是一个例子：在C＃中，类型和变量位于单独的命名空间中；编译器足够聪明，可以知道区别。但是，在C语言中，两种名称都共享一个名称空间，因此在同一范围内不能具有相同名称的类型和变量。因此，C需要一种命名约定来区分类型和变量，而C＃则不能。

我很惊讶没有其他人这么说，但是我认为大写差异非常有用，原因之一是：知道变量是否仅在本地范围内，这很好而且很方便。如果该变量是局部变量，那么我不必担心更改它的副作用，例如重构名称。所以我喜欢一个区分类成员与私有类变量与局部变量的约定。

对于现代的Intellisense，这越来越不重要了，但是当我阅读代码以了解应该在哪里找到定义时，它仍然给我一些地标。

几年前我的风格较差时，可能还剩下一些，那时方法不太适合放在一个屏幕上。

这似乎更像是一个约定问题，而不是您的特定约定。

对于您违反的每项惯例，您只是为其他所有人增加了更多工作。也许在一个完美的世界中，整个公司在整个生命中都使用一种产品……但是，事实并非如此。人们在项目之间跳来跳去，有时跨公司甚至是为了娱乐。代码越随机，处理起来就越困难且成本更高。作为企业所有者或利益相关者，我不想雇用自私自利的开发人员，而不是为了项目的利益。

这归结为专业精神：有时我们需要抛开个人风格，而选择更有效地被大众采用的产品。这鼓励了协作，并消除了本来不应该存在的外部障碍。

根据您的实际约定，CapitalCamelCase通常为类名保留（或在Javascript中为构造函数）。如果我看到一个大写的变量，则有根据的猜测将决定我需要实例化它才能使用它。如果那是错误的，我会很生气，因为该代码没有遵循社区标准。即使使用大多数其他语言，其他人第一次看到它也会立即被误导。我希望代码很明显，不要引起误解。

“因为应该为属性和void方法保留完全适当的大小写。返回值的局部变量和方法应该使用小写的第一个单词”，因为这是标准约定。

其他程序员现在正在拉起您的代码，并认为这是一个属性，并且它实际上是一个局部变量，这使您的工作更加困难。

正如其他人所说，没有什么真正的理由，只是不遵循命名约定。如果您可以让整个团队都在同一页面上，则可以节省一些时间。举例来说，我个人开始编写一个编码标准的东西，我们将camelCase用于所有私有变量以及由Val传递的东西，而我们将PascalCase用于公共事物和由Ref传递的东西。

处理诸如protected或Out之类的东西时，线条会变得有点模糊。

语言（包括形式和传统的语言）对于组织您的思想很重要，它对您的思维方式具有影响力。因此，从一种样式过渡到另一种样式只是一种痛苦。

小写和大写符号在Haskell中有很大的语义差异，在Scala中也略有不同，我已经使用了它们。我使用的其他语言在这两种标识符之间没有区别，但是让我以Haskell感知标识符的方式思考比对分散不同语言的思想要容易得多。

对我来说，这归结为期望。

当我阅读大多数代码时，我期望以a开头的任何东西lowerCase都是局部变量或函数（在C＃中只是变量）。如果我在中看到一个局部变量ProperCase，我可能会迷迷糊糊一会儿，以为它是类名，属性或其他名称。那会导致我重新阅读代码，并且会惹恼我。

您的情况很可能正在发生这种情况。

另外，仅通过查看第一个字母就能知道变量扮演什么角色，这很方便，并且避免了实例名称和类名称之间的冲突。

局部变量应使用小写字母，以便于键入（速度/无移位键）。大写字母用于通过分隔名称中的单词来提高可读性。具有单字局部变量名称（应该是通用的）的代码可以快速简便地键入。与使用添加下一个字符的下划线相比，对名称中的每个新单词使用大写字母的速度也更快（且空间更少），这也称为驼峰式大小写。

我在这里同意OP。camelCase看起来不对。我也同意以下事实：这是标准，我们必须坚持相同的标准或制定标准的意义。当不使用为您的方法着色的IDE时，PascalCaps可以用于方法等，而camelCase可以用于您自己的变量等，这是有区别的。

为了解决这个问题，我总是在对象名称之前加上对象的类型。因此，如果它是一个字符串变量，我称之为strMyVariable。如果它是某种对象，则将其称为objMyObject，以此类推。按照标准，它以小写字母开头，看起来不错。