我有一个同事,他坚持认为他的代码不需要注释,这是“自文档”。

我已经审阅了他的代码,虽然它比我看到的其他人编写的代码更清晰,但我仍然不同意自文档化代码与经过注释和文档化的代码一样完整和有用。

帮我理解一下他的观点。

什么是自文档代码 它真的能取代注释良好和文档化的代码吗 在某些情况下,它是否比有良好文档和注释的代码更好 是否存在代码不可能在没有注释的情况下自文档化的例子

也许这只是我自身的局限性,但我看不出这怎么能成为一种好的练习。

这并不是一个争论——请不要提出为什么注释良好并有文档记录的代码是高优先级的原因——有很多资源都表明了这一点,但它们对我的同行来说并没有说服力。我认为我需要更全面地了解他的观点,才能说服他。如果你有必要,可以提出一个新的问题,但不要在这里争论。

另外,那些反对自我记录代码的人——这主要是为了帮助我理解自我记录代码传播者的观点(即积极的方面)。


当前回答

以下是我对你的问题的最佳回答。

自文档代码是用类、方法、函数和变量名称清晰编写的代码,这些名称使其意图和函数易于理解。如果做得好,它就是文档。

它可以取代注释和文档完善的代码,但我很少见到它。很多时候,程序员认为他们已经足够好了,但是打倒他们的最好方法是开始问问题。如果他们不得不开始解释太多,那么他们的代码就不够清晰。您不应该阅读代码来了解它的功能。

在某些情况下,这样做会更好。如果代码又小又简单,那么添加文档可能会把事情弄得乱七八糟。

包含算法的代码应该包含注释。大多数时候,即使是最初的程序员也不记得几个月前他们在写一个长函数时到底在想什么。

其他回答

大多数文档/注释都是为了帮助未来的代码增强者/开发人员,从而使代码可维护。 通常情况下,我们会在稍后的时间回到我们的模块来添加新功能或优化。 在那个时候,通过简单地阅读注释来理解代码要比通过大量的断点来理解代码容易得多。 此外,我宁愿花时间思考新的逻辑,而不是破译现有的。

在编写数学代码时,我有时发现写一篇类似文章的长注释很有用,解释数学、代码使用的符号约定以及它们是如何组合在一起的。我们在这里讨论的是数百行文档。

我试着让我的代码尽可能地自文档化,但当我几个月后重新开始工作时,我确实需要阅读解释,以免把它弄得乱七八糟。

当然,这种极端的措施在大多数情况下是不必要的。我认为这个故事的寓意是:不同的代码需要不同数量的文档。有些代码可以写得很清楚,以至于不需要注释——所以要写得清楚,不要在那里使用注释!

但是很多代码确实需要注释才能有意义,所以写得越清楚越好,然后使用尽可能多的注释……

我曾经和一个家伙一起工作,他打算把金融套件卖给一家大公司。他们坚持让他记录源代码,他写了一个30多页的汇编程序,并说“这是有记录的,看”——然后他翻到第13页,有一条评论“bump counter by one”。 伟大的产品,伟大的实现者,但是……

无论如何,在我看来,上面的重要评论是为了设置上下文。这段代码是自记录的:

> from BeautifulSoup import
> BeautifulSoup, Tag def
> replace_a_href_with_span(soup):
>     links = soup.findAll("a")
>     for link in links:
>         tag = Tag(soup, "span", [("class", "looksLikeLink")])
>         tag.contents = link.contents
>         link.replaceWith(tag)

但是,就我个人而言,需要一个背景来充分理解它。

对于许多有效的答案,我想再提供一个观点:

什么是源代码?什么是编程语言?

机器不需要源代码。他们很高兴运行组装。编程语言是为了我们的利益。我们不想写汇编。我们需要理解我们在写什么。编程就是写代码。

你能读懂你写的东西吗?

源代码不是用人类语言编写的。它已经被尝试过(例如FORTRAN),但并不完全成功。

源代码不能有歧义。这就是为什么我们必须在其中加入比文本更多的结构。文本只适用于上下文,当我们使用文本时,我们认为这是理所当然的。源代码中的上下文总是存在的。想想c#中的“使用”。

大多数编程语言都有冗余,这样编译器就能在我们不连贯的时候发现我们。其他语言使用更多的推理,并试图消除冗余。

类型名、方法名和变量名在计算机中是不需要的。它们是供我们参考的。编译器不理解语义,这是我们要用的。

编程语言是人与机器之间的语言桥梁。它必须对我们来说是可写的,对他们来说是可读的。次要要求是它应该对我们来说是可读的。如果我们擅长语义,并且擅长构建代码,那么即使对我们来说,源代码也应该很容易阅读。最好的代码不需要注释。

但是复杂性潜伏在每个项目中,您总是需要决定将复杂性放在哪里,以及吞下哪只骆驼。这些是使用注释的地方。

我会扭转局面。

问问自己在他的代码中有什么不理解的,然后让他把这些记录下来。也许你也可以告诉我们一些。