由于我有大量的业余时间花在ATM上，我在这里阅读了一些关于代码注释和文档的线程/评论。 正如大多数人在这里我也认为你应该编写代码，以便尽可能容易阅读和自我评论。 另一方面，我是一个巨大的FP-fanboy - 是的，如果你以正确的方式编写代码，它在FP中会非常易读 - 或者我认为。 问题是微小的东西在FP世界中产生了很大的不同。如果您的同事不完全理解FP，他可能能够“读取”代码的缩进，但无法修改或完全理解它。这代表像Haskell这样的语言，其中一个'。'或者'$'对于像F＃这样的语言甚至是带有大量LINQ语句的VB.NET的C＃都有很大的不同。
乍一看问题可能是，你的同伴只是没有得到语言，而不是代码错误 - 另一方面：谁真正获得了所有的FP？看看有关Haskell的一些文章 - 代码精心制作并自我评论，但就像在数学中你可能需要在线上咀嚼几分钟才能得到它。
当然，在那些论文中，会有一个文本块试图在代码之后澄清......
所以恕我直言，你必须评论你的FP代码，只要你在一个不是每个同事都有CS博士学位的商店工作;）
您怎么看？
PS：这里的第一篇文章 - 真的找到了关于这个问题的答案，但没有找到任何答案 - 如果我看起来不够努力，请保持温柔：）
答案 0 :(得分：5)
函数式语言非常有利于自我编写代码的开发，因为您可以自由地重新排列函数的顺序，并轻松地抽象出代码的任何给定部分，并为其指定一个解释性名称。
抽象，抽象，抽象，是掌握代码复杂性的关键词，这就是功能风格的闪耀点。但总会有一些事情无法在代码本身中表达出来。
一个明显的例子是算法代码。通过查看实现，人们不太可能轻松理解复杂的算法。是的，函数式语言使理解更简单，因为许多血腥细节（简单的例子：内存管理）不必明确编码，从而更清楚地暴露底层逻辑。
然而，这不能替代自然语言的解释，它以直观的方式传达它是如何工作的（有时候一张图片胜过千言万语）。这是因为我们的大脑需要从不同的角度观察困难的概念，以便充分理解它们。
评论内容还取决于您的受众群体。初学者，普通程序员还是向导？没有一个通用的解决方案。
E.g。你应该解释一下“。”的含义。如果你正在编写教程代码，那么Haskell中的（函数组合），但对于任何已经超过任何Haskell书的第一章/第二章的人来说，这肯定是一个多余的解释。
另一方面，一些特定的算法，比如红黑树，可能是某些程序员给出的，对其他人来说则是非常神秘的。在第二种情况下，您应该在代码中添加许多注释，或者指向包含进一步说明的文档。
最后，人们应该注意到即使在主人之间也没有达成共识。例如。 Dennis Ritchie以评论非常简约而闻名，而Don Knuth则是“文学编程”的倡导者，评论与代码本身一样重要。一套规则永远不会取代个人品味。