你在变量名中使用文章吗？答案

【问题标题】：Do you use articles in your variable names?你在变量名中使用文章吗？
【发布时间】：2009-04-09 12:26:27
【问题描述】：

编辑： Smalltalkers 这样做似乎至少有两个正当理由（消息链接期间的可读性和范围问题），但也许这个问题可以保持更长时间以解决一般用法。

原文：出于我早已忘记的原因，我从不在我的变量名中使用冠词。例如：

人，车，物体

我想我觉得文章用毫无意义的信息弄脏了名字。当我看到使用这种约定的同事的代码时，我的血压会略微升高。

最近我开始学习 Smalltalk，主要是因为我想学习 Martin Fowler、Kent Beck 和许多其他伟人在成长和喜爱的语言。

不过，我注意到 Smalltalkers 似乎在其变量名中广泛使用不定式冠词（a, an）。下面的 Setter 方法就是一个很好的例子：

name: aName address: anAddress.
     self name: aName.
     self address: anAddress

这让我重新考虑了自己的立场。如果像 Smalltalkers 这样受人尊敬和有影响力的社区广泛采用了变量命名方面的文章，那也许是有充分理由的。

你会用吗？为什么或为什么不？

【问题讨论】：

自己的名字：aName；地址：一个地址 :-)

标签： coding-style smalltalk

【解决方案1】：

此命名约定是 Kent Beck 的Smalltalk Best Practice Patterns 一书中的模式之一。恕我直言，这本书即使对于不爱说话的人来说也是必不可少的，因为它确实有助于命名事物和编写自记录代码。此外，它可能是少数展示 Alexander's quality without a name 的模式语言之一。

另一本关于代码模式的好书是Smalltalk with Style，即available as a free PDF。

通常，惯例是实例变量和访问器使用裸名词，参数使用不定冠词加上角色或类型，或组合。临时变量可以使用裸名词，因为它们很少重复实例变量；或者，为了表明它们在控制流中的作用，通常更精确地命名它们而不是不定冠词：eachFoo、nextFoo、randomChild...

【讨论】：

阿门。 Smalltalk 最佳实践模式在教我如何使用代码本身（而不是 cmets 或文档）作为交流媒介以及如何培养代码美学方面非常有用。
顺便说一句，“smalltalk 最佳实践模式”现在也可用于 Java，它被称为“实现模式”。

【解决方案2】：

它在 Smalltalk 中通常用作无类型语言，因为它在方法调用中提示参数的类型。文章本身表明您正在处理指定类的某个对象的一个实例。

但请记住，在 Smalltalk 中方法看起来不同，我们使用所谓的关键字消息，在这种情况下，文章实际上有助于提高可读性：

anAddressBook add: aPerson fromTownNamed: aString

【讨论】：

这是一个很好的观点：帮助代码看起来更具可读性。这与很多关于 DSL 的讨论有关，Smalltalk 是创建 DSL 的主要语言，部分原因是这样的消息串在一起..

【解决方案3】：

我想我刚刚找到了一个的答案。正如 Konrad Rudolph 所说，他们使用这种约定是出于技术原因：

...这意味着它[方法变量]不能重复实例变量、接口中定义的临时变量或另一个临时变量的名称。 -IBM Smalltalk Tutorial

基本上，局部方法变量不能与对象/类变量命名相同。来自 Java，我假设方法的变量将是本地范围的，并且您可以使用以下方式访问实例变量：

self address

我仍然需要进一步了解 Smalltalk 中的方法/本地范围，但他们似乎别无选择；他们必须使用与实例不同的变量名，因此 anAddress 可能是最简单的方法。仅使用 address 会导致：

Name is already defined ->address

如果你已经定义了一个实例变量地址...

【讨论】：

我也在语言中使用了类似的约定，其中变量的名称不能与其类型相同，所以我会使用类似“Person aPerson = new Person”的东西。我认为至少 Pascal 或 Delphi 就是这种情况。有人可以同意吗？

【解决方案4】：

我总觉得文章用无意义的信息把名字弄脏了。

没错。这就是放弃文章的全部原因：它们不必要地使代码混乱，并且没有提供额外的信息。

我不了解 Smalltalk，也无法谈论“他们的”约定的原因，但在其他任何地方，上述情况都成立。在 Smalltalk 约定背后可能有一个简单的技术原因（例如 Ruby 中的ALL_CAPS，它不仅按照约定，而且由于语言语义，它是一个常量）。

【讨论】：

哎哟。为什么所有的反对票？不管有没有任何关于 Smalltalk 的知识，这篇文章在本质上仍然是正确的，并且是所有其他语言的一个很好的指南。我什至（或多或少正确，我可能会补充！）推测了 Smalltalk 特殊角色的原因。不要自吹自擂，而是……

【解决方案5】：

我在使用它时来回摇摆不定。我认为这取决于在任何给定时间我的项目中 C++ 与 Objective C 的比率。至于依据和推理，Smalltalk 普及了对象是“事物”的概念。我认为是Yourdon 和Coad 强烈推动了以第一人称描述类。在 Python 中，它类似于以下 sn-p。我真的希望我能记住足够多的 SmallTalk 来组合一个“合适的”示例。

class Rectangle:
    """I am a rectangle. In other words, I am a polygon
    of four sides and 90 degree vertices."""
    def __init__(self, aPoint, anotherPoint):
        """Call me to create a new rectangle with the opposite
        vertices defined by aPoint and anotherPoint."""
        self.myFirstCorner = aPoint
        self.myOtherCorner = anotherPoint

总的来说，它是一种提高程序可读性的会话方法。在变量名中使用冠词只是整个习语的一部分。还有一个关于参数命名和消息选择器 IIRC 的习语。比如：

aRect <- [Rectangle createFromPoint: startPoint 
                    toPoint: otherPoint]

这只是另一种时常流行的时尚。最近我注意到像myHostName 这样的成员名称正在C++ 代码中作为m_hostName 的替代品出现。我越来越迷恋这种用法，我认为这有点像 SmallTalk 的习语。

【讨论】：

【解决方案6】：

从未使用过，可能是因为在我的主要语言中没有任何文章：P

反正我觉得只要变量名有意义，有没有文章并不重要，看程序员自己的喜好。

【讨论】：

那会是斯拉夫语吗？我现在正在学习捷克语，缺乏文章让我抓狂。
实际上几天前我们想知道 Smalltalk 的近似英语语法如何在俄语或其他结构与英语不同的语言中工作。例如， German-smalltalk 可以发送完整的消息加上参数作为一个大的复合词；）

【解决方案7】：

不。我觉得这是浪费字符空间并削弱了代码的可读性。我可能会根据上下文使用名词的变体，例如 Person vs People。例如

ArrayList People = new ArrayList();
Person newPerson = new Person();
People.add(newPerson);

【讨论】：

【解决方案8】：

不，我没有。我不觉得它为我的代码库的可读性或可维护性增加了任何东西，并且它不会以任何方式区分变量。

另一个缺点是，如果您鼓励使用变量名称的文章，那么有人在您的代码库中这样做只是时间问题。

var person = new Person();
var aPerson = GetSomeOtherPerson();

【讨论】：

我想我永远不会理解对主观问题的理性回答如何被否决。至少添加评论

【解决方案9】：

在我工作的地方，标准是所有实例字段都以“the-”为前缀，局部变量以“my-”为前缀，方法参数以“a-”为前缀。我相信这是因为许多开发人员使用的是 vi 等文本编辑器，而不是 IDE，因为 IDE 可以在每个范围内显示不同的颜色。

在 Java 中，我不得不说我更喜欢它而不是编写取消引用 this 的 setter。

比较

public void setName(String name) {
    this.name = name;
}

对

public void setName(String aName) {
    theName = aName;
}

最重要的是要有一个标准，并让每个人都遵守它。

【讨论】：