我似乎总是使用一些单调的词语,如节点、属性、子元素(等等),我担心其他人会因为零碎的名称不明确而难以理解我的代码。
你如何为类和组件找到创意的名称,使它们更易记忆?
对于那些没有实际描述但具有通用功能目的的工具,我尤其感到困惑。我希望知道其他人是否发现了富有创造性的命名方式,而不仅仅是按照其实用性进行命名,比如AnonymousFunctionWrapperCallerExecutorFactory
。
我似乎总是使用一些单调的词语,如节点、属性、子元素(等等),我担心其他人会因为零碎的名称不明确而难以理解我的代码。
你如何为类和组件找到创意的名称,使它们更易记忆?
对于那些没有实际描述但具有通用功能目的的工具,我尤其感到困惑。我希望知道其他人是否发现了富有创造性的命名方式,而不仅仅是按照其实用性进行命名,比如AnonymousFunctionWrapperCallerExecutorFactory
。
在敏捷(和模式)文献中,使用“隐喻”是一个常见的主题。
“孩子”(在您的问题中)是一个广泛使用且具有充分理由的比喻的例子。
因此,我鼓励使用隐喻,前提是它们适用且不是一种想象。
隐喻无处不在于计算机中。从文件到错误到指针到流...你无法避免它们。
我认为节点、子节点和属性是很好的名称。仅凭它们“平淡无奇”的名称,我已经可以猜出你的类以下面这些方式定义:
我不认为“node”既模糊又常见,如果你正在编写一个通用数据结构,使用通用名称可能是可以的!(话虽如此,如果你正在编写树,则可以使用TreeNode之类的名称来强调该节点是树的一部分。)让将使用您的API的开发人员更轻松的一种方法是遵循您所在平台内置库的命名约定。如果每个人都称呼节点为节点,迭代器为迭代器,那么生活就会变得容易。
反映类、方法或属性目的的名称比创意名称更易记。现代IDE使使用更长的名称更容易,因此可以尽情描述。创意并不能像准确性一样有所帮助。
我建议从特定的应用领域选取名词。例如,如果您正在将汽车放入树中,请称节点类别为Car - 它也是一个节点这一事实应该在API中明显。此外,在实现时不要尝试太过通用 - 不要将汽车的所有属性都放入名为properties的哈希表中,而是创建单独的属性,如制造商、颜色等。
$isAvailable = true;
尝试
$bool_isAvailable = true;
虽然它确实让人感到痛苦,但通常它是值得花费时间的。
我也喜欢使用长名称来描述事物。这可能看起来很奇怪,但通常更容易记住,特别是当我回来重构我的代码时。
$leftNode->properties < $leftTreeNode->arrayOfNodeProperties;
如果所有的方法都失败了,为什么不退而求其次,用一个坚实的星球大战主题程序。
$luke->lightsaber($darth[$ewoks]);
$Kube->canEat($myShorts, $withKetchup);