私たちはこのオープンソースプロジェクトを世界中の人々に提供したいと考えています。このチュートリアルの内容をあなたが知っている言語に翻訳するのを手伝ってください。通常はそれを使用して、どうやって/なぜそのコードが動作するのかを説明します。コメントすることは当たり前かもしれませんが、プログラム初心者は間違った思い込みをすることがあります。説明するのにコメントを使う傾向があります。コメントは最小限にすべきです。真面目にそれらがなくても理解しやすいコードにするべきです。それに関して素晴らしいルールがあります。“もしもコードがコメントを必要とするほど不明瞭な場合、書き直すべきかもしれません”。して括られた、よりよりパターンです。true;}今や、私たちは簡単にコードを理解することができます。関数自身がコメントになります。}}改めて言いますが、関数自身が何が行われているのかを伝えているので、コメントすることは何もありません。分割するとコードの構造はより良くなります。各関数がすること、何を引数として取り、何を返すのかは明白です。コメントを避けることはできません。コードの中で行われることがあります。一般的にはコードをシンプルで自己記述的に保つよう努めるべきです。良いコメントこれまでの通り、説明的なコメントは通常良くありません。それは高水準のアーキテクチャ図のための特別な言語UMLがあります。これは間違いなく学ぶ価値があります。...}このようなコメントにより、関数の目的を理解し、コードの中を見ることなく正しい方法で利用することができます。ような多くのエディタも同様にそれらを解釈することができ、それらを使ってオートコンプリートや自動コードチェックを提供します。ようなツールもあります。タスクがこのように解決されるのはなぜか?書かれていることは重要です。そのタスクがこの方法で正しく解決されるのか?コードは回答しません。そのタスクを解決する方法が多数ある場合、なぜこれを選んだのでしょう?特に、それが最も明白なものではないとき。あることを確認します。方法を使って書き直します。書き直したいという思いは良かったです。解決策は実際には不十分であることに気付きます。実は既に以前試みたことであり、なぜダメだったのかぼんやり覚えています。最終的に元の正しい方法に戻します。その分時間が無駄になりました。解決策を説明するコメントはとても重要です。それらは正しい方向で開発を続けるのに役立ちます。コードの捉えにくい特徴はある?それらはどこで使われる?もしもコードが捉えにくく、紛らわしいものがある場合にはきっとコメントする価値があります。何を書くか、また、何を書かないかさえ、指標となります。よいコメントはコードを上手く維持し、時間が経った後でそこに戻ったときにも効果的に使えるようにします。伝えるコードを、コメントを必要としないような、シンプルで自己記述的にすることが不可能な場合にのみ置きます。それらはコメントを解釈し、HTML-docs(または別の形式の文書)を生成します。前のレッスン次のレッスンシェアチュートリアルマップコメントコメントをする前に読んでください...自由に記事への追加や質問を投稿をしたり、それらに回答してください。タグを使ってください。codepen...)。記事の中で理解できないことがあれば、詳しく説明してください。Kantorプロジェクトについてコンタクト。