“有趣的评论”是不好的做法吗？[关闭]

我想问你在源文档中添加一些“复活节彩蛋”是否不专业。也许您已经阅读StackOverflow的民调源文档中有趣的评论，我曾亲自在许多这样的事情我在工作中的公共API文档中跌跌撞撞，包括搞笑的（或不）的东西（例如该弱BZZZTT !! 1！事情在Android公共文档中，我至少可以提供更多示例。

我不能对我自己有最终的意见，因为我自己有矛盾的论点。

赞成论点：

• 它可以使某人振作起来，并使他/她的一天变得更加有趣/更有效率。源代码的主要部分无论如何都不需要注释（如果项目正确完成），因为特定的方法（例如）是不言自明的，或者如果它是一堆奇怪的cr脚代码，则不能会以有意义的方式进行解释，因此开个有趣的笑话不会损害您可以从文档中获得的可能信息。

缺点参数：

• 如果您非常专心/沮丧，那么您最后需要做的就是愚蠢的笑话，而不是给您有关文档代码部分所需的信息，这只会使您更加沮丧。如果所有人都开始这样做，那么文档的外观将是一个可怕的想法。另外，开玩笑的人可能是唯一认为这很有趣/有趣/值得浪费时间阅读的人。

你怎么看？

我认为有趣的评论会浪费时间-浪费时间，浪费时间阅读，浪费时间向同事展示（几乎总是）令人费解的有趣言论，等等。

但是...实际上，没人每天都能每天工作100％（如果这样做的话，这样的网站将是空的），而真正的幽默会破坏一天并有助于保持士气。

我仍然会投票反对，只是因为我读过的每一个“有趣”评论在当时都可能很有趣-但我还没有看到一个实际上很有趣的评论，大多数只是令人费解或对本书的深入了解。 -玩笑。

如果有趣的评论实际上很有趣，那会改变我的想法。但是，一旦您鼓励开玩笑，您是否会鼓励咒骂，侮辱或恶意？

我非常喜欢有趣的评论。

您的评论始终应该是专业的，但是幽默不会杀死读者。

尤其是当读者是您团队的一员时。

我最不喜欢的是开发人员，他们过于重视自己。我认为我们应该在工作中获得乐趣，否则工作是不值得的。

如果它有含义，那就很好笑。用有趣的方式解释评论中的内容是可以的。但是，如果这只是有趣的事情，并且不包含任何实际值作为注释，那就太烦人了。始终记住，发表评论的原因是为了提高维护效率。幽默不必与之相抵触，但是如果做得不好的话也可以。

代码是供...多次阅读的。

在百分百讲完后，您知道多少个笑话很有趣？

有趣的评论很棒。

• 它给您看似无聊的代码带来了积极的氛围。
• 如果您正确地确定了时间安排，那么比正常的无聊评论做得更好。这里的“计时”是指与注释下方代码的相关性。
• 您的代码将被许多人记住，因为在（人类）记忆中情感被赋予了更好的位置。如果您希望更多的人与您一起进行开源项目，这是一个很好的技巧。
• 通常对评论有帮助。它使您的代码更易于使用。当然，您首先应该专注于编写良好的代码。我觉得当人们对他们编写的代码充满信心时，有趣的评论只是一种副作用。

只是不要像这个家伙一样有趣;）

这是我早上两点写的（“ DQ”是我公司的首字母缩写）：

// Twas the night before go-live and all through DQ
// the devs were all crying and yes, this means you.
// Keys had been saved with both hyphens and 'scores
// which left this programmer with finger pad sores.
// The solution I crafted, you'll likely find lacking:
// to OR them together with judicuous hacking.

$hyphenated = str_replace('_','-',$data_type_key);
$underscored = str_replace('-','_',$data_type_key);
// (and then see line 46)

如果您正在客户面前审查源代码，您会感到尴尬吗？

当前的答案似乎都没有考虑到这一点。一些客户没有幽默感，会把这些笑话当作您不认真对待工作的指标。他们会推断您对工作不小心。

有趣的代码注释有时可能不专业且不合适。

除了已经说过的话，如果您在国际团队工作，您的一些海外同事可能不会开玩笑，因为某些本地文化参考或某些单词演奏被某些英语为母语的人无法理解。开源项目也是如此。

如果它是有效的并且没有浪费读者的时间（无论是阅读还是理解），那么我一点幽默都不会觉得有问题。

就像现实世界中的笑话一样，如果您一直都在开玩笑，那不是很有趣，没有生产力，也没有专业精神。但是所有笑话都有时间和地点，代码中也有时间和地点。就像在现实世界中一样，它知道在何处，何时以及如何开玩笑。

取决于，对于大学的作业，我几乎总是在做有趣的评论，因为我知道它永远不会被使用，而只是一项家庭作业。

对于更严肃的项目，我仍然会在这里和那里使用它们，但是不那么普遍，因此它令人讨厌或难以理解，违背了评论的目的。

我记得做过一些Web编程，我不得不回避浏览器的不兼容性和奇怪的故障。有时，文件的结尾处充满了愤怒和仇恨.js。

我的基本经验法则是：如果代码部分的作用显而易见，那么请打开FUNNY COMMENTS！

如果代码如此晦涩难懂（如“ 内联类 ”），那么我最好使用注释，我会在几天之内了解自己。