一部のopensouceライブラリにコメントがないのはなぜですか？

これがほとんどのオープンソースライブラリで発生するかどうかはわかりませんが、私が知っている多くのライブラリ（OpenSSL、Webkitなど）はすべてコメントがないか、コメントがほとんどありません。

非常に少数のドキュメントは言うまでもなく、ソースコードを読むのは困難です。メンバー変数が何を意味するのか、またはこの関数が何をするのかはほとんど理解できません。これはコーディング標準の慣行に反しているようです

何故ですか？コメントをほとんど付けずに、これらのオープンソースに人々が協力するにはどうすればよいですか

ソースコードを書くのは楽しいです。

ドキュメントを書いてコードにコメントするのはあまり面白くない。

開発者が良いコメントやドキュメントを強制する会社で働いている場合、選択肢はありません。この開発者がそれらを作成するか、解雇されるリスクがあります。

開発者がオープンソースプロジェクトに貢献するとき、彼はそれを無料で、特に楽しみのために行っています。ドキュメンテーションやコメントを書くなど、この開発者に望まないことを強制する人は誰もいません。

これが、多くのオープンソースプロジェクトが広範なドキュメントとコメントを欠いている理由です。

ドキュメントやコメントのないオープンソースプロジェクトに、ユーザーはどのように貢献できますか？

• ソースコードが高品質であれば、コメントはそれほど必要ありません。パブリックインターフェイスとドキュメントのコメントは、プロジェクトの利用者、つまり単にライブラリを使用するだけで開発者には貢献しない開発者にとって特に役立ちます。

• 関連する生産性の要因はありません。私は、実際のコードベースに単体テスト、ドキュメント、コメントがない会社で働いています。600-LOCメソッドが何をしているのかを理解するために多くの時間を費やしたり、すでに行われていることをコーディングしたりしていますが、ドキュメントが不足しているため発見できません。貴重な。

  一方、オープンソースプロジェクトの場合、ドキュメントの欠如や適切なコメントのために、貢献者の1人が1週間も無駄になったかどうかは問題ではありません。起こり得る最悪の事態は、この寄稿者がプロジェクトを離れることです。

  コメントやドキュメントなしでコードを発見するのは難しいかもしれません。

• エンタープライズプロジェクトでは、開発者が製品のすべての側面に取り組むことを余儀なくされ、数年後、システム全体をほとんど知る必要があります。オープンソースプロジェクトでは、誰もがすべてを知ることを強制されません。ドキュメンテーションを必要とせずに、その一部に貢献するだけで、この部分の優れた知識を持つことができます。

いくつかの理由。

• ドキュメントを書くのは楽しいことではありません。多くのプロジェクトでは、ユーザーベースはプログラミングチームです。誰もがコードの内容を知っているため、ドキュメントはプロジェクトの重要な側面とは見なされていません。
• ドキュメントは古くなる可能性があり、今後も古くなります。また、古くなったドキュメントは、まったくないよりも悪いです。つまり、ドキュメントは追加の責任であり、コードベースの柔軟性に影響を与える可能性があります（より多くのドキュメントは、コードとドキュメントを更新する必要がある変更に対して意味します）。特に非常に具体的なオープンソースプロジェクトの場合、これは実際には最小限のドキュメントを目指して、代わりに読み取り可能なコードを書くための有効な引数です。
• オープンソースソフトウェアの経済性は異なります。プロジェクトに寄稿者がいることは良いことですが、多くのプロジェクトは、作者が特定の問題を解決するために作成し、そのままオープン状態で放り投げたスクラッチアンイッチタイプのプロジェクトです。基本的に他の人のブレッドクラムを食べているので、態度はあなたが何も要求する立場になく、ドキュメンテーションはありません。

コメントをほとんど付けずに、これらのオープンソースに人々が協力するには

「読みづらいこれらのオープンソースコードに人々がどのように協力できるのか」という意味だとしたら、まあ、悪いコードを含むオープンソースプロジェクトは、優れたコードの場合よりも貢献者が少ないと思います。ただし、コードの可読性は常にビホルダーの目にあることを忘れないでください。ほとんどのオープンソースコードは、少なくとも一部の関数やクラスの意図を理解できないほど悪くはありません。

多くの場合、オープンソースプロジェクトに何かを提供したい場合、全体を理解する必要はなく、特定の機能を追加したい部分のみを理解する必要があります。したがって、開発者が不足している機能を必要とする場合、おそらく弾丸を噛み、変更する必要のある部分を特定し、その部分を精神的に「デコード」して、そこに新しい機能を追加します。彼が上手い人なら、「デコードされた」部分をレビューしてリファクタリングしようとするでしょうが、実際にはこれはめったに起こらないと思います。