「面白いコメント」は悪い習慣ですか？[閉まっている]

ソースドキュメントに「イースターエッグ」を追加するのは専門的でないかどうかを尋ねたいと思います。おそらく、あなたは読んだのStackOverflowの例えば（パブリックAPIのドキュメントで、この弱いソースドキュメントの面白いコメントを投票して、私は個人的に面白い（またはしない）を含め、私の仕事の間に、多くのそのようなことでつまずいているものBZZZTTを!! 1！の事をAndroidの公開ドキュメントでは、少なくとも12個以上の例を挙げることができます）。

私は自分自身と矛盾する議論をしているので、私は自分自身について最終的な意見を出すことはできません。

プロの議論：

• それは誰かを元気づけ、彼/彼女の一日をより面白く/より生産的にすることができます。ソースコードの大部分は、とにかくコメントする必要はありません（プロジェクトが適切に行われている場合）。特定の方法（たとえば）が自明であるため、または奇妙なくだらないコードの山である場合、意味のある方法で説明されているので、面白い冗談は、ドキュメントから取得できる情報を害することはありません。

短所の引数：

• あなたが非常に集中している/欲求不満の場合、最後に必要なことは誰かの愚かな冗談です。文書化されたコード部分について必要な情報を提供する代わりに、それはあなたをさらにイライラさせます。そして、もし誰もがそうし始めたら、ドキュメントがどのように見えるかという考えは恐ろしいです。さらに、冗談を書く人は、それを読むのが面白い/面白く/時間を浪費する価値があると考える唯一の人かもしれません。

どう思いますか？

面白いコメントは時間を無駄にするものだと思います-書くための無駄な時間、読むための無駄な時間、（ほとんど常に）単に不可解な面白い発言を同僚に示すための無駄な時間などです。

しかし...毎日誰も実際に毎日100％で働いているわけではありません（このようなサイトは空の場合は空っぽでしょう）。

私が今まで読んだすべての「面白い」コメントが当時面白いかもしれないという理由だけで、私はそれに対してまだ投票します-しかし、私はまだ実際に面白いもの、ほとんどが単に不可解であるか、深い-冗談で。

面白いコメントが実際に面白い場合、それは私の心を変えるでしょう。しかし、ジョークを奨励したら、宣誓、encourage辱、悪意を奨励しますか？

私は面白いコメントの大ファンです。

コメントは常に専門家である必要がありますが、ユーモアによって読者を殺すことはありません。

特に読者があなたのチームのメンバーである場合。

私が最も嫌いなのは、自分自身を真剣に考える開発者です。私たちは仕事で楽しい時間を過ごすべきだと思います。

意味があれば、面白くても大丈夫です。コメントで何かを面白い方法で説明するのは問題ありません。ただし、それがおもしろいだけで、コメントとして実際の値が含まれていない場合、それは単に迷惑です。コメントの理由は、メンテナンスをより効率的にするためであることを常に念頭に置いてください。ユーモアはそれと対立する必要はありませんが、適切に行われなければ可能性があります。

コードは読むためのものです...何度も。

100回目の発言の後、面白いジョークをいくつ知っていますか？

面白いコメントは素晴らしいです。

• 一見退屈なコードにポジティブな雰囲気を与えます。
• タイミングを正しく取得できれば、通常の退屈なコメントよりも説明がはるかによくなります。ここで「タイミング」とは、コメントの下のコードとの関連性を意味します。
• 感情は（人間の）記憶の中でより良い場所を与えられるため、あなたのコードは多くの人に記憶されます。これは、オープンソースプロジェクトでより多くの人に協力してもらいたい場合の素晴らしいトリックです。
• 一般的にレビューに役立ちます。これにより、コードの耐久性が大幅に向上します。もちろん、まず良いコードを書くことに集中する必要があります。自分が書いたコードに自信があるとき、面白いコメントは副作用に過ぎないと感じます。

この男のように面白くしないでください;）

朝の2時に書いたもの（「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ファイルの怒りと憎しみに満ちたコメントで終わることもありました。

私の基本的な経験則は次のとおりです。コードセクションが何をするかがある程度明らかな場合は、面白いコメントを有効にしてください。

コードが非常に不明瞭で地獄のように難読化されている場合（「インラインクラス」など）、コメントを使用した方がいいでしょう。