生き様019. 良いコード悪いコード普通のコード
「カッコいいコード」って何だろう？
先日、とある新人プログラマーさんとお話していた時に
「カッコいいコードが書けるようになりたい」
と言われました。
ハテ？カッコいいコードってなんでしょう？
僕の尺度に、カッコいいコードって存在しないんですよ。
残念ながら、その人とはそれ以上そのお話を深める事ができなかったのですが…
今回は、白栁流コードの「良い/悪い」の基準について、お話しようと思います。
良いコード、悪いコードの基準
僕のコードの評価基準はシンプルです。
【読みやすく、メンテナンスしやすい】
シンプルといいつつ、【読みやすい】【メンテナンスしやすい】の基準が不安定過ぎて、とても難しいです。
「ちょっと洒落た事をやろうとして、複雑なコードを書いたら、他の人が全然読めないコードができた」
なんて事はよくあります。
若い頃は「省略できるものは省略して、短く複雑なコードが書ける俺スゲー！！」みたいな事も言ってました。
「俺は読みやすい」と言い張る同僚と、読みやすいコードについての激論を交わした事もありますし、
難読コードと呼べる酷いコードを紐解いてメンテナンスした事もあります。
そんな経験を経て、ぼんやりと【読みやすい】コードと【メンテナンスしやすい】コードの方向性が見えてきました。
「読みやすいコード」とは？
「読みやすいコード」と言うと、真っ先に挙がるのが「リーダブルコード」という、少し前に流行った書籍です。
僕も一通り目を通していますが「当たり前の事しか書いてないな」という感想で終わりました。
「僕にとっては当たり前だった」、この事実だけで十分な収穫でした。
そして「なんとなく書いたコードが読みやすいなんて事はありえない」という事もよく分かりました。
なので、ここから一歩進んでみます。
僕が工夫して心掛けている「読みやすいコード」の書き方の目標は「頭を使わずに読める」事です。
考えて読み解かなければいけないのなら、それは既に「読みやすいコード」ではない、と考えています。
細かいコーディングの技術をこの場で語りませんが、
コメントを利用したり、定数や列挙で値に意味を持たせる方法で「今、ここで何をしているのか」を分かりやすくする様にしています。
でも、それ以上に心掛けて居ることが「コーディングのルールを守る」です。
言語やプロジェクトごとに、コーディング規約があります。
それに、プログラミングにも定石と言われる書き方があります。
そういうルールをしっかりと下敷きとした上で、ちょっと個人的な趣味を載っけた程度。
そのぐらいのコードが、読みやすいコードの基準になると考えています。
それぞれの優先度を図にするとこんな感じです。
「保守しやすいコード」とは？
「保守しやすいコード」で一番重要なのは「何をやってるか判る事」です。
つまり、読みやすいコードであることがポイントになるのですが、それ以外の方法もあります。
それは「メンテナンスの必要がないコードを書く」です。
例えば
- 良く変わる計算式を外部ファイルへ記載できる様にする
- 条件により変わる部分をパラメータとして受け取れる様にする
という方法があります。
例えば消費税税率。
多くのロジックでは「期間と税率をペアにしたデータを用意し、時期により正しい税率で計算できる様にする」でしょう。
消費税の税率が変わるタイミングでは、期間と税率のペアを増やすだけで良いのです。
メンテナンスが必要無いのならば、少しぐらい複雑で読み辛いコードを書いても良いのでしょうか？
個人的には、そういう部分でもなるべく分かりやす様にするべきだと考えます。
引き続き消費税税率の話です。
2019年10月に消費税に「軽減税率」という新しい仕組みが追加されました。
品物の種類・用途によって、2種類の税率のどちらかを適用する必要が出たのです。
メンテナンスの必要が無かった税率計算ロジックを、刷新する必要ができてしまいました。
この様に、ある程度の拡張性を考えて居たコードでも、想定外の拡張が入ると弱いものです。
最近、メンテナンスの必要がない様に組んだ複雑なロジックに、想定外の修正が入って涙目な僕の実体験です。
今回のまとめ
読みやすく、メンテナンスしやすいコードを書きましょう！
せめて、コーディング規約は守って下さい！！
近々、先人の書いた、コーディン規約全然守ってない、個人の趣味だけで書かれた、読むだけで苦行なコードと格闘し無ければいけない僕の、心からの叫びです。
おしらせ
2020年2月24日（月・祝）に行われる『Object-Oriented Rejected Conference 2020 [非公式]』で初登壇します。
しかも一番手！！（※申し込み順です）
まだまだ席に余裕があるそうなので、是非！