出于好奇，我开始怀疑一种不允许注释的语言是否会产生更具可读性的代码，就像您被迫编写自我注释的代码一样。

再说一遍，您可以编写与以前一样糟糕的代码，因为您根本不在乎。但是您有什么看法？

我认为程序员会想出另一种添加注释的方法。

string aComment = "This is a kludge.";

我认为不是那么简单：

即使在编写良好的自文档代码中，在某些情况下也应编写注释。

假设您是一个完美的程序员（虽然您不是，但让我们假设）...

当您与未编写的内容进行交互时，代码中会发生很多非显而易见的影响。例如，其他人的库或其他人的硬件中（如果您是内核开发人员）可能存在设计缺陷。使用注释来解释为什么在特定的地方使用特定的kudge对于理解代码和确保不删除（破坏事物）至关重要。

对于这样的想法，我很难全神贯注：从语言中删除选项会以某种方式使使用该语言编写的程序更好。注释不是强制性的，编写自文档代码也不是必需的。

良好的开发实践无可替代。

从理论上讲，COBOL最初的设计方式是要具有足够的自我文档记录能力，即使是非开发人员（即主管）也可以查看所编写的代码并确定正在发生的事情。但是，实际上，随着程序变得越来越复杂，很难理解仅通过代码进行的所有操作。

虽然删除注释可能会迫使一些开发人员编写的代码是更好的在自我的文档，还有开发人员在那里，写记录不完整代码（IE的变量名a，b，c，等），它是这些习惯的人需要训练出的。在这种情况下，删除注释不会影响那些开发人员，并且可能会阻碍其他开发人员解释复杂代码的工作。

编写每个程序都是为了实现程序外部的功能要求，无论是写下来的还是仅仅在别人的脑海中。

我认为注释的最基本功能是在需求和代码之间建立映射。需要映射的原因是允许增量更改。当需求发生变更时，如果代码仍是需求的解决方案，则有必要对代码进行相应的更改。这些评论可作为更改的路线图。

如果该语言是理想的领域特定语言（DSL），完全适合要解决的问题，则映射应该是简单的同构，并且不需要注释。源代码将仅说明问题，而无需赘述。该问题的解决方案将埋藏在语言的实现中。

由于我们使用的语言不是DSL，并且会保留一段时间，因此我们仍然需要注释。这是一个程度的问题。有时，问题是与手头语言的良好匹配，但通常并非如此。

也可以看看...

我在不允许内联注释的地方工作（即，您只能在函数顶部添加注释）。不，它不会使代码更易于阅读。它使数量级恶化。

我避免注释代码，并且它可以工作。

我避免使用所有代码内（行内或流内）注释，而推荐使用docblock +有意义的变量+ spartan编程，它可以工作。

是的，我知道docblock从技术上来说仍然是注释，但实际上它们是对代码的补充，不是侵入性的和“标准化的” ...所有普通注释都不是。

我认为可以替代注释的内容：标准化的docblock语言/语法/惯用语，类似于Java中的注释。

正如其他人所观察到的那样，它不仅不会影响质量，而且实际上会很烦人。

我敢肯定，我们大多数人都会时不时地做这样的事情：

foreach ( myObject obj in SomeList )
 {
    Debug.Writeline( obj.Name );
//  for some reason this isn't working
//  obj.SetArielPotency( setting );
//  obj.DoSomeProcess();       
 }

如果您无法注释出几行代码来找出该错误的来源，那将是多么烦人？

不管对代码如何运行有任何评论，像这样的简单实际操作或放入方便的TODO注释都可以使您更轻松地解决小问题并记住我们在开始编写代码时所做的事情。

评论就像一本书的摘要。当然，您可以通过阅读代码来理解所有内容，但是为什么当您可以将整个页面总结在一个注释行中时，为什么还要阅读整个页面呢？

尽管我同意其他答案，甚至自文档代码也需要注释，但这仅与当前语言相关。

我认为真正的问题是：“是否有可能设计一种不需要注释的新编程语言？” 它需要非常高的抽象程度。通过该语言的语法，每个语句和函数都将被强制可读。

无论语言如何，无纪律的程序员都会编写错误的代码。

有趣的是，按照惯例，它只有私有的（_-prefix）Python并没有做出任何努力来管理这一点，并且仍在编写许多精美的代码。

兰特：有时候我认为，更多的宽松语言会迫使更多的人学习正确的编码，而不是相反（例如，如果您想将函数视为一流的对象，那么Java是唯一的选择，那该死的）。

我猜：可能不会。为什么？因为您必须将“为什么”编码为语言的形式主义，并且因为“为什么”无论是用语言编码还是使用语言注释，程序员仍然没有使用。

代码可以肯定是自我注释的解释是什么它是干什么的，但它并不总是可能的代码解释为什么它是做什么的。那是最需要评论的地方。

例如，如果需要一段代码来遵守特定法规，那么您如何在不加注释的情况下对此加以解释？如果由M. Matsumoto和T. Nishimura在1998年撰写的一篇论文中描述了特定代码所使用的算法，那么您如何在不加评论的情况下对此加以解释？如果算法不能完全提供最佳功能，但是会做出非常具体的合理折衷，如果更改其他代码，可能会导致将来出现问题，那么如何在不加注释的情况下进行解释？

如果代码的一部分由独立的审核员审核，那么在不使审核无效的情况下不能对其进行修改，并且该代码用于构建客户要求其遵守该审核的产品，该怎么办。您如何表示不加评论？

我一直认为，用一个单词注释可能会很好，这样，如果您在一个单词前加上一个符号（比如冒号），则该单词将被忽略。这样一来，您可能已经说不准了，它只允许在s表达式中包含一个单词的注释。例如，您可以打开以下代码：

(if (= x y)
    x
    y)

...变成这样：

(if (= x y)
    :then x
    :else y)

如果绝对必要，则可以链接多个单字注释以形成内联注释：

(if x :Remember, :x :could :be :nil!
    ...)

当然，这很难打。实际上，这就是重点。它鼓励您谨慎使用内联注释，并使它们简短明了。但是我觉得我很难说服任何人使用该语言。

这是一无是处。一些程序员不做任何使代码可读的事情。不允许发表评论会加强这一点。有些程序员写好的注释，即使使用代码重构而不是注释会更好，即使删除注释也可能会迫使他们进行更好的重构。

这是个好主意的原因：-无

这是一个不好的主意的原因：-比善良但又不伟大的程序员残暴的程序员更多- 奇怪的陷阱，摘要等几乎总应该有一些注释-即使您回避注释，您也可能会使用在进行评论的阶段：在编写内容时抛出评论，然后返回并重构它。但是您不能总是马上就做，因为您还在学习。-鼓励人们围绕它努力工作-谁会使用它？编写无法理解的代码并想要找个借口的人（不好的一面）和已经迷上这个主意的人（他们一开始只能“不写评论”）。如果这是您想要的，只需编写一个编码标准，说明您希望人们如何做到这一点。

可能相关的原因-可能有用的地方是使“未评论”更好的系统的一部分。一种语言或IDE，对某些事物的支持优于评论，并且作为其推销的一部分，避免使用注释。我不知道它将如何工作，但这是一个值得至少思考的好点。