使用仅与大小写不同的变量名是否不道德？

例如，使用这段代码：

var person = new Person();

或适合您的Pythonista用户：

person = Person()

经常有人告诉我这有多糟，但是还没有看到这两行代码不道德的例子。在我看来，人就是人，而尝试给它起另一个名字是浪费时间。我想在语法突出显示之前的日子里，这会是一件大事。但是如今，很容易分辨出类型名和变量名。哎呀，这很容易看出SO的区别。

还是我想念的东西？如果是这样，如果您可以提供一个导致问题的代码示例，将很有帮助。

那些告诉你这很不好的人的理由是什么？我一直都这样做。这是命名类型的单个变量的最简单的表达方式。如果需要两个Person对象，则可以person添加有意义的形容词作为前缀

fastPerson
slowPerson

否则就

person

我很好。

我在方法签名中经常使用此模式。如果我无法提供其他描述性名称，那么恕我直言，这没有什么不妥。

错误的是，如果您有两种类型的Person和person，那将是非常非常错误的。

我一直使用它来临时引用对象。我会避免像原始数据类型那样困扰。

Person person = new Person(); // okay

int Int = 42; // pure evil

如果有人说这是邪恶的，请问他们是否更好：

var abc = new Person();

如果该人员在上下文中是一般人员，则“人员”是一个很好的名字。当然，如果此人在代码中具有特定角色，则最好使用该角色来命名她。

我想我会因为这样说而被否决，但是...

刚刚经历了一个世纪的史诗般的谋杀和贪婪，如果我们能做的最不道德的事情是给变量命名，那么我们的程序员真的很幸运。

我不认为它一定是“坏的”，但是很显然，如果您可以限定它以提供更多的上下文信息，例如它是什么样的人（您正在与可能的许多人中的一个打交道），那么其他人会选择它起来可能更好理解。

杰森-我不确定是谁告诉你这很糟糕。许多作者将此作为表达类（大写）的实例（小写）的标准方法。

我经常使用它，因为我发现小写变量实际上向我传达的信息不仅是实例，而且是类的名称。

除非有人有明确的相反观点，否则我一定会继续这样做。

被认为是不好的原因是，如果您将来需要2个人，则可以得到类似如下的代码。

Person person = new Person（）;

人person2 =新的Person（）；

那将与“坏”接壤。但是，在这种情况下，您应该重构原始人，以区分两者。

对于您的示例，变量名“ person”是对象“ Person”的完美描述性名称。因此，它没有任何问题。

我说出它的名字：如果变量表示一个有2条狗的人，请称其为personWith2Dogs。如果变量的作用域很短（如循环变量），那么person就可以了。

我在代码中使用了很多，并且认为它没有任何问题。就是说，我（可能）不会以比一个屏幕更长的方法使用它，并且如果有Person类的多个实例的话。绝对不要将它们命名为person1，person2，person3 ...而是使用更具描述性的名称，例如person_to_del，person_to_ban，person_to_update等。

这不是不道德的，但是如果您未能激活区分大小写的内容Person，person那么全局搜索将同时找到两者。我更喜欢使用前缀来简化全局搜索/替换，但绝对不是匈牙利语或冗长/复杂的东西。所以，我用...

Person用于aPerson局部变量的类/类型 ，thePerson用于方法变量 的方法参数 myPerson，ourPerson用于类变量的实例 变量

在极少数情况下，我可能会p在有很多引用的本地上下文中使用，但这通常仅适用于循环索引等。

这取决于。

如果您具有严格的大写样式，则变量以小写字母开头（并使用under_scores或camelCase进行分词），而类以大写字母开头，那么很明显person是变量，而Person是类，当有人理解了这一点时，它们似乎不会出现在重叠的名称空间中。（类似地，人们几乎永远不会混淆动词或名词“ polish”与形容词“ Polish”之间的混淆。）

如果您没有这样的样式，那么您就有两个容易混淆的名称，只是大小写不同。那很糟。

人们使用的确切论点是什么？

如果他们不允许您使用person作为变量名，则可以考虑添加'a'前缀。

aPerson = Person()

我想你在做什么很好。我认为一般来说，达成一致的编码标准很重要。

例如，我将lowerCamelCase用于实例，将变量和UpperCamelCase用于类等

编码标准应消除此问题。

当我查看成功的开源程序时，它们通常具有编码标准

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

同意编码标准应该是您对此进行的最后一战。

实际上看一下Wikipedia条目（来自http://en.wikipedia.org/wiki/CamelCase）

编程和编码风格

有时，建议使用内部大写字母来表示用于编写源代码（例如，Mesa编程语言和Java编程语言）的编码样式准则的单词边界。其中一些准则中的建议由检查源代码是否符合要求的静态分析工具支持。

这些建议通常区分UpperCamelCase和LowerCamelCase，通常指定对特定种类的实体应使用哪种变体：变量，记录字段，方法，过程，类型等。

一种广泛使用的Java编码风格要求将UpperCamelCase用于类，将lowerCamelCase用于实例和方法。[19] 认识到这种用法，某些IDE（例如Eclipse）实现了基于CamelCase的快捷方式。例如，在Eclipse的“内容辅助”功能中，仅键入CamelCase单词的大写字母将建议任何匹配的类或方法名（例如，键入“ NPE”，而激活内容辅助则可能建议“ NullPointerException”）。

最初的匈牙利编程符号表示，“用法类型”（而非数据类型）的小写缩写应在所有变量名称之前加上其余名称，并在UpperCamelCase中使用；因此，它是LowerCamelCase的一种形式。CamelCase是Java和Amiga个人计算机中文件名的正式约定。

Microsoft .NET建议对参数和非公共字段使用lowerCamelCase，对于其他类型的标识符建议使用UpperCamelCase（也称为“ Pascal样式”）。[20]

Python建议使用UpperCamelCase作为类名。[21]

NIEM注册表要求XML数据元素使用UpperCamelCase，而XML属性使用LowerCamelCase。

在CamelCase名称中没有大写缩写（主要是缩写和缩写）的统一约定。方法包括将整个缩写保留为大写（例如在“ useHTTPConnection”中）和仅保留首字母为大写（例如在“ useHttpConnection”中）。

骆驼盒在计算中绝不是通用的。几种现代编程语言的用户，尤其是Lisp和Forth家族的用户，几乎总是使用连字符。有时给出的原因包括大多数键盘上不需要这样做，分开的单词更易读，并且骆驼的大小写可能无法可靠地保留在不区分大小写或区分大小写的语言中（例如Common Lisp，尽管从技术上讲区分大小写，但默认情况下会将标识符规范化（折叠）为大写）。

可能会提出一个更强有力的论据，即这种方法名称不仅无害，而且可以指示高质量的代码。

• 良好的代码粒度的指标：如果您的方法简短，用途单一且具有描述性的名称，则变量名中不需要太多信息。如果您有很长的方法可以执行很多事情，并且需要跟踪很多上下文和状态，那么您的变量名需要更具描述性。

• 通用计算的指标被下推到通用方法中：如果您在业务方法中对数据结构进行中间操作，例如必须对用户数组进行重复数据删除，则必须在范围内使用变量与users[]和一样的名字deduplicatedUsers[]。如果将重复数据删除移至实用程序方法，则可以调用该方法Utils.dedup(array)，也可以调用重复数据删除数组deduplicatedArray或just result。

• Java反编译器通常使用类似的方案来命名局部变量（实例和类变量通常在字节码中可用，但是局部变量不可用），并且结果比您期望的更易读，实际上通常比原始来源。

• 见的Larry Wall的原则“本地歧义是OK” - http://www.wall.org/~larry/natural.html 。

我想说，每次创建对象时，您可能都会想到一些特定用途。单独的类型很少反映这种使用。

因此，如果要在通讯录应用程序中创建新联系人，则可能需要调用变量newContact。

而且，如果您正在对代码进行单元测试以检查Person未设置名称的对象的行为，则可能需要调用它们unnamedPerson或类似名称。

简单地称呼它 person可以使代码自我记录。

仅当您在VB6中编程时。在这种情况下，您所做的是违法的，但不是不道德的。

我也这样做，我也不明白为什么它应该是“不道德的”。尽管我可以理解它有时可能会造成混淆，但是今天我们有了具有智能感知和语法突出显示功能的IDE，可以确保（如果您犯了一个错误并引用了变量而不是类，反之亦然）很快看到您的错误。而且我们还有编译器。:)

我也认为这种做法没有任何问题。只要该类只有一个变量，就易于编写和阅读。Imo，甚至适用于基本的文本编辑器。我个人不记得有人称其为不良甚至不道德。只是继续这样做:)

我认为您可能想到的“规则”更多地用于原始类型，以及类名使变量名差的类。

例如，如果您要处理在线商店中特定商品的成本计算，那么以下代码将不是一个好格式：

Decimal _decimal = item.BaseCost + item.Tax;

而是建议使用更具描述性的名称，例如'_total'或'_cost'。

我发现的这种问题的唯一问题是，您是否要为私人成员和公共财产使用相同的名称。

如果这些仅在大小写上有所不同，则可以在区分大小写的语言（例如C＃）中正常工作，但在VB.NET中则不能。

因此，例如，在VB中，我会写

Private _name As String

但

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

我会在C＃中做同样的事情，这样就可以轻松地进行从一个到另一个的转换。这也使它更不容易出错，因为它很容易被误读，或者实际上是错误键入的单词（仅因大小写而异）。

这不是不道德的，但是如果变量的最佳名称是类型的名称，则可能是错误的，或者您只是在进行概念证明或类似的证明。对我来说，变量名必须指代业务上下文中的含义，而不是指编程语言。理解代码会更加困难。

我经常用Person person = new Person()自己。常用于Java / C＃。

虽然昨天我最后想知道为什么

private enum DataType {NEW, OLD}

在C＃中不起作用...

尤其是看到你如何使用String，string，Double，double，...在C＃意志。

Person person = new Person()

我的书很好。

当您患有以下情况时，它变得可怕起来：

string Person;
string person;

非常容易混淆2。

除了不符合我们的编码标准外，向我表达的是要避免在其他人阅读我的代码时增加混乱。我个人认为只要含义清楚就没有问题。

至于CLR类型（int，string等），您可以使用String或string（等）来声明类型，因此我避免使用类似

int Int = 0;
string String = "hi there";

使大写唯一的区别是危险的...继续为大型项目这样做，我保证您会遇到似乎无法找到的奇怪错误。

像上面的fastPerson / slowPerson很好...它们是描述性的，并且与变量类型名称有所区别...但是拜托，将int称为“ Int”会很懒。

我会说它永远不会不道德-它实际上只是您的基准变量名称。如果您想不出一个更好的名字，那么在它的类型后再命名是一个很好的默认值。（仅对于复杂类型-对于内置类型，这是邪恶的）而且很多时候，确实没有更好的名字，因为您没有对变量一无所知。喜欢这种方法

void SaveToDatabase(Person person) {...}

关于您可以合理称呼的唯一一件事就是person_to_save看起来很多余的东西。

但是，在很多情况下，可以通过使用更具描述性的名称代替person来提高代码的可读性。例如，这不是描述性的

void AddToAccount(Account account, Person person)  {...}

比这个

void AddToAccount(Account account, Person dependent)  {...}

但是，请，请-请不要在类型名称前添加“ a”或“ t”。IE aPerson代表“一个人”或tPerson代表“该人”。它过于复杂，并没有增加太多价值。另外，您开始使用一堆以a或t开头的变量来污染范围，这些变量可以使智能感知的值最小化。

我不会说这太可怕了。在这种情况下，我通常会在变量名称前加上“ a”，以表明它是该类型的单个实例，因此我会这样做

Person aPerson = new Person();

我认为它使代码阅读更自然。

绝对没有错，但要注意其他人提出的警告（为方便起见，在此处进行总结）：不对原始类型执行此操作，如果稍后添加另一个实例，则重构原始实例，不使用char-case区分类名，等等。

我的经验法则？代码中的语句应看起来像简单的英语句子。

Person person = new Person（）;

雇员雇员= person.getRole（EMPLOYEE）;

父母父母= person.getRole（PARENT）;

person.getFullName（）;

employee.getSalary（）;

parent.getChildren（）;

parent.getFullName（）; //假设正在使用装饰器模式

如果（person.hasRole（EMPLOYEE））{

  ...

}

依此类推。

如果变量的范围是有限的（例如，封装方法是10-15行），我什至可以使用'p'而不是'person'。尝试将上下文保留在头脑中时，较短的变量名会减少干扰。避免使用不必要的前缀，例如“ a”或（颤抖）匈牙利符号及其分支。（请注意，在适当的上下文中使用C ++ / COM / ATL / Win32 API代码等时，我对此类前缀没有任何要求，在这里它有助于保持分配/类型转换的正确性）。

我的两个（！）位:-)