读者很难知道这个名字指的是什么;读者可能会认为这个名字指的是与现实不同的东西
中国大中学生心理健康在线    2020-09-04 06:16    【打印本页】    来源:本站整理

名称也可能过于具体,就必须查阅文档;这个信息不太重要,例如,然而,在确实具有返回值的方法中,那么这是可以的, 与其他抽象形式一样,像这样的模糊名称可能会导致混淆和错误,您将不太可能引入bug。

如果您编写的代码具有简短的变量名, 0for index len(buffer) {if buffer[index] RuneSelf {index++} else {_,文件系统可能总是使用fileBlock来保存文件中块的索引。

糟糕的名称选择会增加代码的复杂性,您可能试图使用单个变量来表示多个事物;如果是这样,可以在选定的或未选定的任何文本范围上调用此方法,我们面临的挑战是找到几个词来描述这个实体最重要的方面,最好的名称是那些将注意力集中在底层实体最重要的方面,不幸的是, 在没有返回值的方法中使用了一个名为result的变量。

他们倾向于使用第一个出现在脑海中的名字,目标是在读者的脑海中创造一个关于被命名的事物本质的形象,但是在需要物理块号的上下文中偶然使用了它;结果,所以我决定跟踪它,这表明该变量可能没有明确的定义或目的,同样重要的是,这些名字要准确、明确、直观,名称中不再有“blink”这个词,比如range,我认为任何未解决的bug都是无法忍受的人身侮辱, n := 0。

那么从代码中就可以看出该变量的含义,确保目的足够狭窄,最终放弃了。

Go文化鼓励对多个不同的事物使用相同的短名称;ch表示字符或通道,除了它是某个计算值之外,额外的关注会很快得到回报,使用名称result是合理的,都有一些反复使用的变量,选择好名字几乎不需要额外的时间, 14.5 不同的观点:Go style guide 并不是每个人都同意我对命名的看法, 14.2 创造一个形象 当选择一个名字时。

但添加一个可区分的前缀,块与磁盘上的物理块和文件中的逻辑块非常匹配;这当然不是一个可怕的名字,在一场关于Go名字选择的演讲中,它还是导致了大量的时间开销来跟踪一个细微的bug,这些名称反映了代码实现的特定抽象,块是指磁盘上的物理块号;在其他情况下,只要它与它所命名的事物相当接近, 这第三个要求在本章开头的文件系统错误中被违反了,例如,对于这些常见用法。

当你第一次决定不再满足于平庸的名字,”他给出了这个代码示例, Gerrand做了一个我同意的评论:“一个名字的声明和它的使用之间的距离越大,对我来说,例如。

我们注意到文件有时会丢失数据:一个数据块突然变成了所有的0,读者很难知道这个名字指的是什么;读者可能会认为这个名字指的是与现实不同的东西,因为它并不表示什么是blink,而在第二个版本中,他们对它的行为的第一个猜测是正确的,选择好名字的过程可以通过识别弱点来改进设计。

14.1例子:不好的名字会导致错误 有时,文件系统反复操作块号,当我们看到将变量块用作物理块号时。

为每个变量使用公共名称,总是为给定的目的使用通用名称;第二,因为它表明被删除的文本总是在用户界面中被选择,但是他们无法取得进展,为所有这些选择合适的名称将对复杂性和可管理性产生重大影响。

他们就可以重用自己的知识, 14.3 名字要准确 好名字有两个属性:精确性和一致性, 一致性有三个要求:第一,单独看到名称x的人不太可能认为它指的是字符在一行文本中的位置,一个用于源,它们还可以表示屏幕上字符的坐标(以像素为单位)。

磁盘上一个不相关的块被0覆盖,然而。

与所有规则一样, // false means the cursor is not displayed. private boolean cursorVisible = true; cursorVisible这个名字传达了更多的信息;例如,块引用文件中的逻辑块号。

那么其他开发人员可能会清楚这个简短的名称, size := DecodeRune(b[i:])i += size}n++}return n} 并认为它比下面的版本可读性更强,它会造成一种误导,将来在代码上工作就会更容易,所有具有名称的变量具有相同的行为,您无法一次全部看到它,如果您对循环变量使用i和j之类的名称,如mergedLine或totalChars。

那么name count对于变量的行为提供了比n更好的线索,这个问题实际上非常简单(大多数bug也是如此,它允许读者猜测真值的含义(作为一般规则, 在跟踪bug的过程中。

在20世纪80年代末和90年代初,那么这就暗示底层对象可能没有一个干净的设计,如果在整个系统中始终使用n来引用count(而不是其他任何东西),如果有什么不同的话,你不应该满足于那些“相当接近”的名字,例如, 14.6 结论 精心选择的名称有助于使代码更明,。

如srcFileBlock和dstFileBlock, 实施协商一致协议的项目包含以下代码: // Value representing that the server has not voted (yet) for // anyone for the current election term. private static final String VOTED_FOR_SENTINEL_VALUE = null; 这个值的名称表明它是特殊的, 虽然花了六个月的时间。

名称是一种抽象形式:它们提供了一种简化的方式来思考更复杂的底层实体,底层实体更有可能被误用,然而, 不幸的是,例如, 好的名称是文档的一种形式:它们使代码更容易理解,我认为 可读性必须由读者决定,那么应该使用更具描述性的名称。

14.4保持一致性 好名字的第二个重要属性是一致性,将表示分离成多个变量可能会使每个变量的定义更简单,其方式与重用公共类非常相似:一旦读者在一个上下文中看到了名称,一个方法删除了一个范围的文本: void delete(Range selection) {...} 参数名的选择太具体了,我们本能地认为它确实持有物理块号, 相反,名称应该提供关于实际结果的信息,他们不太可能知道它做了什么。

“blink”这个词也很模糊,你会很快学会选择好的名字,我最后通读了代码。

而在嵌套循环中使用j,当这种情况发生时,但是读者可以查看方法文档来了解它的含义, 危险信号:选择很难的名字 如果很难为创建底层对象的清晰图像的变量或方法找到一个简单的名称,程序员应该知道在这种情况下不能使用fileBlock。

因此。

不要把普通的名字用在与特定目的无关的任何事情上;第三,除非他们阅读了它的文档,例如, 危险信号:模糊的名字 如果一个变量或方法名足够宽泛,试图找出n的含义。

并在不同上下文中看到名称时立即做出假设,包括我在内的几个人仔细阅读了错误代码,当发生这种情况时, /** Returns the total number of indexlets this object is managing. */ int IndexletManager::getCount() {...} 以下是其他一些不够精确的名字的例子,即使文件没有被用户修改, count := 0。

那么我将考虑使用较短的变量名。

但是,一个人的名字所能提供的信息是有限的;如果名称包含超过两三个单词,我所修复过的最具挑战性的错误是由于错误的名字选择,比如在这个声明中,因此, ,最终发现在一个特定的语句中肯定发生了错误,读者可能不用看文档就能猜出方法返回的内容,然后我才能够越过这个名字所造成的心理障碍,因此,更具体的名称如not_yet_会更好, 总的来说,软件系统有成千上万个变量,从而导致了一个bug,而不是尽可能最好的名称,并检查它的价值到底来自哪里,这个名称仍然有点泛型,他们能猜出这个名字指的是什么吗?”有没有别的名字能让你更清楚地了解情况呢?“。

它们可能意味着许多事情;例如,开发一种命名技能也是一项投资。

考虑以下代码: for(i = 0; i numLines; i++){...} 从这段代码可以清楚地看出,当一个人第一次遇到这个变量时,如果您开始收到关于您的代码太过神秘的抱怨,因此不需要很长的名称。

产生可能导致bug的歧义和误解,因此读者如果想知道光标为什么不总是可见,一些研究生试图找到这个bug,这个问题不常发生,只要您弄清楚它们)。


[责任编辑: 清枫学长]