Justin Duke 询问是否将 代码注释视为脚注 可以帮助我们更好地理解文件中的代码。在他的模拟中，所有注释默认情况下都是隐藏的，需要点击才能显示
真是个好主意！Justin 的设计让我想起了 Instapaper 处理内联脚注的方式。
我想我喜欢这个想法的原因是，很多注释不需要经常阅读，——它们有点像提醒，“嘿，这在将来需要改进”或者“哎呀，这很奇怪，抱歉”。将这些注释从代码中移除，也使得扫描整个文件更容易。
我很好奇是否可以有一个开关显示所有注释，以防您需要按顺序阅读所有注释，而不是点击切换每个注释。
无论如何，所有关于注释的讨论让我想起了今年 Sarah Drasner 在 JSConf 上的一次精彩演讲，她在演讲中讨论了为什么注释如此难以写好
关于如何（不）写注释的另一种观点： https://blog.usejournal.com/stop-writing-code-comments-28fef5272752
这是一种强烈的观点，但自从我开始遵循它之后，我一直在代码中看到改进。它比以前更具自解释性。
类似的东西也可能鼓励更强大的注释，因为您可以在不占用代码中太多视觉空间的情况下写更多信息。我喜欢它！我唯一想建议的更改是为某些注释添加一些语法，使其不折叠。有时我在长 HTML 或 CSS 文档中使用注释作为部分标题，如果可以显示这些标题，同时隐藏关于代码特定部分的描述性注释，那就太好了。
有时代码很复杂，但做的事情很简单。在这种情况下，注释更像是简短的解释，而不是脚注，因此必须可见。
好的代码风格的前提是不需要注释听起来很棒，但实际上，注释不是为了帮助你今天，而是为了帮助你在 3 年后回到代码并理解你当时想做什么。
我见过很多案例，人们错误地使用了 == 而不是 !=，而你正在调试代码，并试图理解他们是否真的想这样做。一个简单的注释，比如
// 当状态不为空时…
可以救你一命。
我喜欢将注释放在可折叠部分中的想法。
我其实对反过来很感兴趣。一种叫做文学编程的东西。把它想象成编写一个带有代码片段的 Markdown 文件。
https://en.wikipedia.org/wiki/Literate_programming
https://github.com/Rich-Harris/lit-node