好奇心から、コメントを許可しない言語は、自己コメントのコードを書くことを余儀なくされるので、より読みやすいコードを生成するかどうか疑問に思い始めました。

繰り返しますが、気にしないので、以前と同じように悪いコードを書くことができます。しかし、あなたの意見は何ですか？

プログラマはコメントを追加する別の方法を考え出すと思います...

string aComment = "This is a kludge.";

私はそれがそんなに簡単だとは思わない：

よく書かれた自己文書化コードであっても、コメントを書くべき合法的な状況があります。

あなたが完璧なプログラマーであると仮定すると（そうではありませんが、考えてみましょう）...

あなたが書いていないものとインターフェースをとっているときに、コードで起こり得る多くの非自明な効果があります。たとえば、他の誰かのライブラリ、または（カーネル開発者の場合）他の誰かのハードウェアに設計上の欠陥がある可能性があります。特定の場所で特定のクラッジを使用した理由を説明するコメントは、コードを理解するために不可欠であり、クラッジが削除されないようにします（破損）。

言語からオプションを削除すると、その言語で書かれたプログラムがより良くなるという考えに心を包むのは難しいです。コメントは必須ではなく、自己文書化コードを書くこともそうではありません。

優れた開発プラクティスに代わるものはありません。

理論的には、COBOLは元々、開発者以外（スーパーバイザー）でさえ記述されたコードをレビューして何が起こっているかを判断できるほど十分に自己文書化できるように設計されました。ただし、実際には、プログラムが複雑になるにつれて、コードだけで行われているすべてを理解することは困難です。

コメントを削除すると、自己のドキュメントで優れているライト・コードにはいくつかの開発者を強制するかもしれませんが、そこに開発者という書き込み不十分な文書化されたコードをまだあります（のすなわち変数名はa、b、c、など）と、それは人々が出て訓練する必要があること、それらの習慣でありますの。そのような場合、コメントを削除してもそれらの開発者に影響はなく、他の開発者が複雑なコードを説明する努力を妨げる可能性があります。

すべてのプログラムは、書き留められているか、誰かの頭の中にあるかを問わず、プログラムの外部にある機能要件を実装するために作成されます。

コメントの最も重要な機能は、要件とコードの間のマッピングを確立することだと思います。マッピングが必要な理由は、増分変更を許可するためです。要件に変更が生じた場合、コードが要件の解決策であり続けるためには、コードに対応する変更を加える必要があります。コメントは、変更のロードマップとして機能します。

言語が、解決される問題に完全に適合した理想的なドメイン固有言語（DSL）である場合、マッピングは単純な同型である必要があり、コメントは不要です。ソースコードは単に問題を述べているだけで、他に何も言う必要はありません。問題の解決策は、言語の実装に埋もれてしまいます。

私たちが働いている言語はそのようなDSLではなく、しばらくの間そうであり続けるので、まだコメントが必要です。それは程度の問題です。時々、問題は手元の言語とよく一致しますが、通常は一致しません。

こちらもご覧ください...

私はインラインコメントを許可しない場所で働いています（つまり、関数の上部にのみコメントを付けることができます）。いいえ、コードが読みやすくなりません。それは桁違いに悪化させます。

コードにコメントを付けないようにします。

docblock +意味のある変数+ 質素なプログラミングを支持して、すべてのコード内（インラインまたはストリーム）コメントを回避し、機能します。

そして、はい、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メモを追加することは、小さな問題を簡単に修正し、コードを書き始めたときに何をしていたかを覚えやすくするものです。

コメントは本の要約のようなものです。確かに、コードを読むことですべてを理解できますが、一体1つのコメント行に要約できるのに、なぜページ全体を読みたいのでしょうか？

自己文書化コードでさえコメントが必要であるという他の答えには同意しますが、それは現在の言語にのみ関連しています。

本当の質問は、「コメントを必要としない新しいプログラミング言語を設計することは可能ですか？」かなり抽象化されたかなり高いレベルである必要があります。すべてのステートメントと関数は、言語の構文を介して強制的に読み取り可能になります。

規律のないプログラマーは、言語に関係なく悪いコードを書きます。

慣例によりプライベート（_-prefix）になっているpythonは、これを取り締まる努力をせず、多くのすばらしいコードがまだ書かれています。

Rant：寛容な言語は、逆ではなく、より多くの人々に適切なコードの学習を余儀なくさせると思うことがあります（つまり、関数をファーストクラスのオブジェクトと考えたい場合は、Javaの唯一の方法です。

おそらくそうではないでしょう。どうして？言語の「形式」として「なぜ」をエンコードする必要があり、言語でエンコードされているか言語でコメントされているかがプログラマによって十分に活用されていないためです。

コードは、それが何をしているのかを説明するのに確かに自己コメントすることができますが、コードがそれをしている理由を説明することが常に可能であるとは限りません。これが、コメントが最も必要な場所です。

たとえば、特定の規制に準拠するためにコードのセクションが必要な場合、コメントなしでどのように説明しますか？特定のコードで使用されるアルゴリズムが、1998年にM. MatsumotoとT. Nishimuraによって書かれた論文に記載されている場合、コメントなしでどのように説明しますか？アルゴリズムが最適な機能を正確に提供しないが、他のコードが変更された場合に将来の問題を引き起こす可能性のある非常に具体的な正当化された妥協を行う場合、コメントなしでどのように説明しますか？

コードの1つのセクションが独立監査人によって監査され、その監査を無効にせずに変更できない場合、そのコードを使用して、その監査への準拠が顧客に要求される製品を構築するとどうなりますか？コメントなしでそれをどのように示しますか？

単語の前に記号（コロンなど）を付けた場合、その単語は無視されるように、1単語のコメントを付けておくといいといつも思っていました。そうすれば、s-expression内で1ワードのコメントしか許可されていないと言うことができます。たとえば、これを有効にできます：

(if (= x y)
    x
    y)

...これに：

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

どうしても必要な場合は、複数の1ワードコメントを連結してインラインコメントを作成できます。

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

もちろん、これは入力するのが面倒です。実際、それがポイントです。インラインコメントを控えめに使用し、短く簡潔にまとめておくことが推奨されます。しかし、私は誰かにその言語を使うよう説得するのは難しいと感じています。

これは二重か無かです。一部のプログラマーは、コードを読み取り可能にするために何もしません。コメントを許可しないと、これが強化されます。一部のプログラマーは、コメントよりもコードリファクタリングの方が良い場合でも、良いコメントを書きます。コメントを削除すると、より良いリファクタリングが強制される場合があります。

これが良いアイデアである理由：-なし

良いが、-大きくないプログラマーよりも多くの凶悪プログラマがあります- -ほとんど常に存在する必要があります：これは悪い考えである理由いくつかの奇妙な落とし穴、要約、などのコメント-あなたはコメントを避けている場合でも、あなたはおそらく使用意志途中の段階としてのコメント：何かを書いているときにコメントを入れてから、戻ってリファクタリングします。しかし、まだ学んでいるので、すぐにそれができるとは限りません。-それは人々がそれの周りで働くことを奨励します-誰がそれを使うでしょうか？読めないコードを書いて言い訳をしたい人（悪い）とすでにそのアイデアに夢中になっている人（「コメントを書かない」ことから始められます）。これがあなたの望むものであるならば、あなたが人々にそれをしたい方法を示すコーディング標準を書いてください。

これが関連する可能性のある理由-有用である可能性があるのは、システムの一部として「コメントしない」を改善することです。コメントよりも優れたものを適切にサポートし、ピッチの一部としてコメントを避けている言語またはIDE。どのように機能するかはわかりませんが、少なくとも考えてみる価値はあります。