创意术语

Question

我似乎经常使用诸如 node ， property ， children （等）等平淡无奇的单词，我担心其他人会很难理解我的代码只是因为部分的名称是模糊的，常见的单词。

如何找到类和组件的创意名称，以使其更难忘？

我特别遇到通用工具的问题，除了它们相当通用的功能目的之外没有真正的描述。我想知道其他人是否找到了创造性的方法来命名，而不是简单地通过实用程序命名，例如AnonymousFunctionWrapperCallerExecutorFactory。

Answer 1

很难回答。我发现它们只是因为它们似乎“适合”。

然而，我所知道的是，我发现基本上不可能继续编写代码，除非正确命名，并且“感觉”很好。如果它没有正确命名，我发现它很难使用，代码通常会令人困惑。

我并不太关心“令人难忘”的事情，只关注“准确”。

众所周知，我坐在那里大声思考什么叫什么名字。慢慢来，确保你对这个名字感到满意。不要害怕使用普通/简单的词语。

Answer 2

使用“隐喻”是敏捷（和模式）文学中的一个共同主题。

'儿童'（在你的问题中）是一个被广泛使用并且有充分理由的隐喻的例子。

所以，我鼓励使用隐喻，只要它们适用而不是想象力。

隐喻在计算机中无处不在。从文件到错误到指向流的指针......你无法避免它们。

Answer 3

我真的没有答案，但你要考虑三件事。

1. 已故菲尔·卡尔顿（Phil Karlton）曾说：“计算机科学只有两个难题。缓存无效和命名事物。”因此，你在提出好名字时遇到麻烦这一事实是完全正常的，甚至是预期的。
2. OTOH，在命名事物时遇到麻烦也可能是设计糟糕的表现。 （是的，我完全清楚，＃1和＃2相互矛盾。或许人们应该认为它更像是相互平衡。）例如，如果一个事情有太多的责任，那么几乎不可能来一个好名字。 （见证不良OO设计中的所有“服务”，“实用程序”，“模型”和“经理”类。以下是"ManagerFactoryFactory"的Google代码搜索示例。）
3. 此外，您的姓名应映射到主题专家使用的域行话。如果您找不到主题专家，那就表明您目前正在担心您不应该担心的代码。 （基本上，应该实现和设计实现核心业务域的代码，辅助域中的代码应该实现和设计一般，所有其他代码根本不应该实现或设计，而是从供应商处购买，您所购买的是他们的核心业务领域。[请大声解释“购买”和“供应商”。社区开发的自由软件就好了。]）

关于上面的＃3，您在另一条评论中提到您当前正在实施树数据结构。除非您的公司从事销售树数据结构的业务，否则这不是您的核心域的一部分。你找不到好名字的原因可能是你在核心领域之外工作。现在，“销售树数据结构”可能听起来很愚蠢，但 实际上是那些做到这一点的公司。例如，微软开发人员部门内的BCL团队：他们实际上销售（好吧，对于某些“卖”的定义，无论如何）.NET框架的基类库，其中包括树数据结构。但请注意，例如微软的C ++编译器团队实际上（从字面上）从第三方供应商处购买他们的 STL - 他们认为他们的核心域正在编写编译器，他们将库的编写留给公司谁考虑编写STL 他们的核心域。 （事实上​​，AFAIK，该公司只做 编写和销售STL实施。这是他们唯一的产品。）

但是，如果销售树数据结构 是您的核心域，那么您列出的名称就可以了。它们是主题专家（在这种情况下是程序员）在谈论树数据结构领域时使用的名称。

Answer 4

我认为，出于标准化和沟通的目的，使用一个共同的词汇是很好的，就像设计模式的相同情况一样。我有一个程序员的问题，他一直在“发明”他自己的条款，我很难理解他。 （他一直使用'事件编排'这个术语代替'脚本'或'FCFS过程'。尽管有创造力的荣誉！）

那些常见的词汇描述了我们习惯的东西。节点是一个点，一个图形中的某个位置，一个树中的或者什么不是。一种方法是特定于域。如果我们正在进行映射问题，而不是'node'，我们可以使用'location'。这在某种意义上是有帮助的，至少对我而言。因此，我发现需要平衡能够与其他程序员进行通信，同时保持描述符的具体性，以帮助我记住它的作用。

Answer 5

我认为节点，孩子和财产都是很棒的名字。我已经可以通过他们的“乏味”名称猜出以下关于你的课程了：

• 节点 - 此类是对象图的一部分
• children - 此变量包含属于包含节点的节点列表。

我不认为“节点”是模糊的或常见的，如果你正在编写一个通用的数据结构，那么通用名称就可以了！ （话虽如此，如果你正在编写树，你可以使用像TreeNode这样的东西来强调节点是树的一部分。）一种方法可以让开发人员的生活更轻松地使用你的API平台内置库的命名约定。如果每个人都将节点称为节点，迭代器称为迭代器，则可以简化生活。

Answer 6

反映班级，方法或财产目的的名称比创意名称更令人难忘。现代IDE可以更容易地使用更长的名称，因此感觉费用是描述性的。获得创意无助于获得准确性。

Answer 7

我建议从特定的应用程序域中挑选名词。例如。如果你把汽车放在树上，调用节点类Car - 它也是一个节点的事实应该从API中显而易见。另外，不要试图在实现中过于通用 - 不要将汽车的所有属性放入名为属性的散列表中，而是为make，color等创建单独的属性。

Answer 8

许多语言和编码样式都喜欢使用各种描述性前缀。在PHP中没有明确的类型，所以这可能会有很大帮助。而不是做

$isAvailable = true;

试

$bool_isAvailable = true;

这无疑是一种痛苦，但通常值得花时间。

我也喜欢用长名字来描述事物。它可能看起来很奇怪，但通常更容易记住，特别是当我回到重构我的代码时

$leftNode->properties < $leftTreeNode->arrayOfNodeProperties;

如果一切都失败了。为什么不回到一个坚实的星球大战主题计划。

$luke->lightsaber($darth[$ewoks]);

最后，在大学里，我把我的课程命名为我的教授，然后我的班级将所有我想做的事情都用于那个混蛋。

$Kube->canEat($myShorts, $withKetchup);