最終的に、コードは (最終的に) CPU の命令にコンパイルされます。ただし、コードは (私の謙虚な意見では) 人間が読み取り、更新し、対話するためのものです。これは、次の観察につながります。
たとえ機能していたとしても、他のエンジニアが読めないコードは悪いコードです。
このことを念頭に置いて、コードを人間が読みやすくするために、このプログラマーは何ができるでしょうか?
命名規則？（ジョエルはそれについてかなりのことを言っています）
コード構造/レイアウト? {(神様の愛のために、配置の議論に参加しないでください)
言い回し？(より英語に近いコードを書くことは可能ですか)
Joel以外にも優れた記事はありますか。
はい。
コンピューターが実行しない場合は、壊れています。人々がそれを読むことができない場合、それは壊れます。後で。
「コンピューターが理解できるコードを書くことは、どんな馬鹿でもできる。優れたプログラマーは、人間が理解できるコードを書きます。」-- Martin Fowler、「リファクタリング: 既存コードの設計の改善」
しかし、あなたはすでに自分でその結論に達しているので、これは大きなトピックであると言えば十分です. ひとつの答えが得られるものではありません。コードを保守可能にすることは、コーディング スタイルに限定されるものではなく、全体的な設計と構築プロセスにも関係します。ほとんどすべての質問と回答がこのトピックに影響を与えるこのサイトのいくつかのタグを次に示します。
プログラムは人が読めるように書かれるべきであり、機械が実行するのは偶然に限られます。
-- Abelson と Sussman による "Structure and Interpretation of Computer Programs" より
コンパイラは、コードがきれいに書かれているか、読めない混乱を気にしません。構文が正しい限り、コードはコンパイルされ、実行されます。
ただし、コードのメンテナンスに関しては、人々にとってきれいに書かれたコードは非常に役立ちます。ビジネスケースの観点からは、新しいプログラマーがコードを理解するのにかかる時間が短いほど、新しい人をスピードアップするために必要なお金が少なくて済みます。したがって、よりクリーンなコードにはより多くの価値があります。プログラマーが理解するのに 100% 長い時間がかかるのに、読めないコードのパフォーマンスが 5% 速くなったとしたら、それは何の意味があるでしょうか? 結局のところ、プログラマーにはかなりの費用がかかります。
スタイル、変数の命名などのコーディング標準に従ってコードを記述することは、複数の人が記述したコードの一貫性を保つために重要です。優れたコーディング標準に従った一貫したコードベースは、より保守しやすくなります。
多くの場合、コードの最適化に関しては、判読不能な混乱になる可能性がありますが、一般的に、最近のコンパイラは最適化に関して優れているため、より明確に記述されたコードは、コンパイラが特定の構造をキャッチして最適化を実行する可能性も向上します。その上で、パフォーマンスの向上につながります。
機械ではなく、人のために書く。
Roedy Green は Unmaintainable Codeという広範なガイドを書きました。
「それを念頭に置いて、このプログラマーは、人間がコードをより読みやすくするために何ができるでしょうか?」
回答: このガイドを読んで、書かれているすべてのことを逆に開発活動に適用してください。
一般原則セクションからの引用:
「メンテナンス プログラマーをだますには、彼の考え方を理解する必要があります。彼はあなたの巨大なプログラムを持っています。彼にはそれをすべて読む時間はなく、ましてや理解することはできません。彼は自分の変更を加える場所をすばやく見つけたいと考えています。外に出て、変更による予期しない副作用はありません。
彼はトイレットペーパーの芯を通してあなたのコードを見ます。彼は一度にあなたのプログラムのほんの一部しか見ることができません. あなたは、彼がそれをすることで全体像を把握できないようにしたいと考えています. あなたは、彼が探しているコードをできるだけ見つけにくくしたいと考えています。しかし、さらに重要なことは、彼が安全に無視できるように、できるだけぎこちなくしたいということです。
プログラマーは慣習によって自己満足に陥ります。ときどき、規則に微妙に違反して、コードのすべての行を拡大鏡で読むように強制します。
すべての言語機能がコードを保守不能にするという考えが浮かぶかもしれませんが、そうではないのは、適切に誤用された場合のみです。」
これは皮肉なことですが、読みやすく保守可能なコードを実際に書きたい場合に避けるべきことの非常に便利なリストです (不快な広告は別として)。
それに対する私の見解は少し的外れです - それは可読性ではなく、保守性です。
読むことは、コードを見て、それを読めると思っているだけです。通常、読めるようになるためには、それを理解する努力をしていない人にも読める必要があると考えられています。
メンテナンスとは、バグを修正したり、新しい/変更された要件を実装するために変更を加えることです。読書はそのプロセスの一部にすぎません。メンテナー側の学習曲線を必要としない保守可能なコードを私は知りません。また、その曲線を登っていない人にとっては、コードは「読めない」ように見えます。
同時に、メンテナーが学習曲線を上るのを助けるように教えることは、プログラマーの責任の一部だと思います。そのための 1 つの方法は、予想される将来の変更をどのように実行するかについて、段階的な指示を残すことです。
空白で膨らませて画面に収まりきらないコードをよく見かけます。また、冗長な名前を付けたり、ばかげたコメントを付けたりしています。これにより、可読性の印象が与えられます。
<sarcasm>コードは機械によって読み取られるだけで済みます。最終結果がユーザーのニーズを満たす限り、コードがどのように見えるかは問題ではありません。</sarcasm>
保守可能なコードまたは変更可能なコードになると、それはまったく別の話です。
ナプキンの裏に走り書きされた図面で家を建てますか、それとも、いつか部屋を追加したいかもしれない家を建てた後、設計図を捨てますか?
Robert MartinのClean Codeを参照することをお勧めします。これは、コードをより読みやすく、きれいにする方法についての優れたガイドです。
これに対する私の見解は、すべてが相対的であるということです。
コードを変更する必要がある場合、コードはあなたのためであり、マシンのために実行される場合です。
コードが機能している場合、読み取られる可能性があります。
あなたの中にある人間的で協調的な存在は、他の人間がコードを簡単に読めるようにする必要がありますが、最終的には、慣例はさておき、コードの読みやすさは見る人の目にかかっている場合があります。
コードが読みやすくなればなるほど、変更や保守が容易になります。進化は、問題に適用する貢献/貢献者の数から恩恵を受けるため、このタイプのコードは、読めないコードよりも優れていると宣言できます。
しかし最終的には、コードはマシンへの一連の命令になります。
人間の意図は、機械が従うことができるものに変換されるため、コードは一度に 1 つずつ、両方を対象としています。
タイプセーフな言語でハンガリー語表記を使用しないでください。
アイテムがありません: コメント。
コードが作成者にとって完全に判読可能であったとしても、それが万人向けであるとは限りません。