良いプログラムコードとは - プラチナプラスチック

つらつら書いていく

良いって言葉を使ってる以上、
完全に主観丸出しの主張になってしまうことは目を瞑ってほしいところ

プログラムを書く人なら一度は考えること、
「良いプログラムコード」

これは特に仕事をする場面で飛び交う言葉で、
悪いプログラムコードでは生産性が下がることを意味する

プログラムを書く上で気をつけているそれを、
ツラツラ書いていこうと、そういうわけだ

俺が思う良いプログラムコードの条件は3つ
優先順位で、

順に説明していく

拡張がしにくいプログラム、
つまり、
入力から出力までが一貫して成り立ってしまっていて、
後付けで機能を加えたくても処理を入れる隙間がないプログラム

これがよくあるのは、
2つの機能を同時に加えたいときで、
1つを加えるともう片方を加えるために大改造をしないといけなくなるパターン

後付け拡張はプログラムを書く上でよくあるので、
ある程度想定されてつくることが望ましい

もうひとつ、連携は、
他のプログラムに出力を渡したり、逆に、
受け取ることが容易であること

プログラムを移植する可能性を考えて、
独立して成り立つモジュールとしてのプログラムは有用性が高い
ライブラリとも言う

役割をエンドユーザーかライブラリかをはっきりさせて、
それぞれで特化していることが望ましい

機能の数だけプログラムが大きくなることは想像に容易く、
また機能が増えるほど複雑さが増していきがち

複雑なプログラムというのは、
一度に多くの情報を処理しようとしてる場合に多い

目的を段階的に細分化していくと、
複雑さがやわらいで、シンプルで、見通しがよくなる
見通しが良いプログラムはバグの発見が早くなる

見通しの良いプログラムは、
目的に対して小さくつくられていることが多い

同じ長さの毛糸も、
絡まっていれば大きく見えるし、
綺麗にまとまっていれば小さく見える

直感で、綺麗だ、と思えたなら、
良いプログラムに違いない

よくプログラムにはコメントを付けろ、と言われる
それは、後から読んだ時や、他の人が読んだ時に理解しやすいようにするためだったりする

だが、コメントがあるから良いプログラムコード、というわけではない
実際に動くのはプログラムなのだから、
焦点はプログラムコード自体に合わせる

プログラムを読む大前提として、
達成しようとしてる目的が不明だと内部の処理が想像できない
関数単位で考えるなら、その関数の目的が何かがわからないと、内部の間違いは指摘できない

まず、目的が一目でわかること
これを助けるのにコメントがあるのは良いが、
どちらかと言えば関数名でわかる方が望ましい

そして内部の処理がコメントで補足するまでもなく、
簡単な手続きで書かれているなら、理解を超えて納得ができるようになる

一度つくったプログラムも、
後から考えてみると意外と、
「こうすればもっと簡単にできたな」ということがある

ソートなんかを知ると情報処理は、
単に処理する順番の問題であることに気付かされる
事態は意外と単純だったりするからプログラムは面白い