创意术语

6

我似乎总是使用一些单调的词语,如节点属性子元素(等等),我担心其他人会因为零碎的名称不明确而难以理解我的代码。

你如何为类和组件找到创意的名称,使它们更易记忆?

对于那些没有实际描述但具有通用功能目的的工具,我尤其感到困惑。我希望知道其他人是否发现了富有创造性的命名方式,而不仅仅是按照其实用性进行命名,比如AnonymousFunctionWrapperCallerExecutorFactory


1
不要忘记为此编写接口,IAnonymousFunctionWrapperCallerExecutorFactory。 - blu
8个回答

4
很难回答。我发现它们似乎“合适”。
然而,我知道的是,除非某些东西被正确命名并且感觉良好,否则我基本上无法继续编写代码。如果名称不正确,我会发现很难使用,代码通常会令人困惑。
我不太关心是否“值得记忆”,只关心是否“准确”。
我已经知道坐在那里大声思考该给某个东西起什么名字。花时间,确保你对这个名字真正满意。不要害怕使用常见/简单的词语。

2
我同意并进一步认为,平淡无奇的名称实际上是一件好事,因为它们很可能会快速传达它们的目的。创意名称应该保留给犯罪小说中的角色。简单、简洁和有意义的名称适用于代码。 - sipsorcery

3

在敏捷(和模式)文献中,使用“隐喻”是一个常见的主题。

“孩子”(在您的问题中)是一个广泛使用且具有充分理由的比喻的例子。

因此,我鼓励使用隐喻,前提是它们适用且不是一种想象。

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


3
我并没有一个确切的答案,但有三件事情供您考虑:
1. 著名的Phil Karlton曾说:“计算机科学中只有两个难题:缓存失效和命名事物。” 因此,您在为事物起好名字方面遇到困难是完全正常的甚至可以预料的。
2. 另一方面,命名困难也可能是设计不良的迹象。(是的,我非常清楚,#1和#2相互矛盾。或者说应该将它们看作相互平衡。)例如,如果一个事物承担了太多职责,就几乎不可能想出一个好的名字。(在不良面向对象的设计中,可以看到所有“Service”,“Util”,“Model”和“Manager”类。以下是对 "ManagerFactoryFactory" 进行的Google代码搜索的一个示例。)
3. 此外,您的名称应该映射到专业领域专家使用的术语。如果找不到专业领域专家,那就是您当前正在担心不该担心的代码的迹象。(基本上,实现您核心业务领域的代码应该被以良好的方式实现和设计,辅助领域的代码应该被以一般的方式实现和设计,所有其他代码不应该被实现或设计,而应该从供应商那里购买。您购买的是他们的核心业务领域。[请自由解释“购买”和“供应商”。社区开发的免费软件也可以。])
关于上面提到的第三点,在另一个评论中,您提到正在实现一种树形数据结构。除非您的公司的业务是销售树形数据结构,否则它不属于您的核心领域。而且,您找不到好的名称的原因可能是您正在处理核心领域之外的工作。现在,“销售树形数据结构”听起来可能很愚蠢,但实际上确实有这样的公司。例如,微软开发部门内的BCL团队:他们实际上销售(嗯,在某些定义下,“销售”).NET框架的基础类库,其中包括树形数据结构等。但请注意,例如微软的C++编译器团队实际上(字面意义上)从第三方供应商那里购买了他们的STL - 他们认为他们的核心领域是编写编译器,并将库的编写留给将编写STL视为他们的核心领域的公司。 (实际上,据我所知,该公司除编写和销售STL实现外,什么也不做。那是他们唯一的产品。)
但是,如果销售树形数据结构是您的核心领域,则列出的名称完全可以。这些都是专业领域专家(在这种情况下是程序员)在谈论树形数据结构领域时使用的名称。

2
我认为为了标准化和交流,使用共同的词汇是好的,就像设计模式一样。我遇到一个程序员,他总是“发明”自己的术语,我很难理解他的意思。(他一直使用“事件编排”这个词,而不是“脚本”或“先来先服务进程”。虽然有创造力,但也有问题!)
那些常见的词汇描述了我们习惯的东西。节点是一个点,在图形、树形结构或其他地方。一种方法是针对特定领域进行具体说明。如果我们正在处理映射问题,我们可以使用“位置”,而不是“节点”。这在某种程度上有所帮助,至少对我来说是这样。因此,我发现需要平衡与其他程序员的交流能力,同时保持描述符足够具体,以帮助我记住它的作用。

2

我认为节点、子节点和属性是很好的名称。仅凭它们“平淡无奇”的名称,我已经可以猜出你的类以下面这些方式定义:

  • Node - 这个类是对象图的一部分
  • children - 这个变量保存属于包含节点的节点列表。

我不认为“node”既模糊又常见,如果你正在编写一个通用数据结构,使用通用名称可能是可以的!(话虽如此,如果你正在编写树,则可以使用TreeNode之类的名称来强调该节点是树的一部分。)让将使用您的API的开发人员更轻松的一种方法是遵循您所在平台内置库的命名约定。如果每个人都称呼节点为节点,迭代器为迭代器,那么生活就会变得容易。


1

反映类、方法或属性目的的名称比创意名称更易记。现代IDE使使用更长的名称更容易,因此可以尽情描述。创意并不能像准确性一样有所帮助。


1

我建议从特定的应用领域选取名词。例如,如果您正在将汽车放入树中,请称节点类别为Car - 它也是一个节点这一事实应该在API中明显。此外,在实现时不要尝试太过通用 - 不要将汽车的所有属性都放入名为properties的哈希表中,而是创建单独的属性,如制造商、颜色等。


如果我有像汽车一样具有描述性的东西来使用就好了。我正在构建一个通用的树形数据结构,可以用于任何事情。:-S - too much php
1
如果这个树形结构确实是通用的,那为什么你还要写它 - 以前肯定已经被写过很多次了。如果有写它的原因,请尝试思考一下这个原因是什么,并将其放入名称中。 - Martin v. Löwis

-1
很多语言和编码风格喜欢使用各种描述性的前缀。在PHP中没有明确的类型,因此这可能会有很大帮助。不要这样做:
$isAvailable = true;

尝试

$bool_isAvailable = true;

虽然它确实让人感到痛苦,但通常它是值得花费时间的。

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

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

如果所有的方法都失败了,为什么不退而求其次,用一个坚实的星球大战主题程序。

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

最后,在大学里,我把我的课程命名为我的教授的名字,然后我的类方法都是我想对那个混蛋做的事情。
$Kube->canEat($myShorts, $withKetchup);

可怕的建议..但还是很有趣 :) 我曾经创建了一个只使用动物名称作为变量的小应用程序。写了2个小时后,我感到非常迷失。不过这是一个理解良好命名的好练习.. - cwap
我正在寻找那种创造力,但仍有意义的方式。 - too much php
不幸的是,无论你有多少创意,你都在远离对程序正在做什么以及变量含义的描述。我认为这就是使用创意变量名的固有问题。正如Meeh所说,并且这篇文章旨在开玩笑,随着名称变得越来越不明显和描述性变差,它们变得越来越不可用。 - jW.
也许我们应该使用外语等效词。这可能有助于我们意识到非英语母语者在使用带有英语关键字的语言进行编程时所需付出的额外努力。 - pavium

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接