経緯
ソースコードの書き方は、人によってそれぞれだけれども、良い書き方が存在する。このことに関して言えば、コードコンプリートやコードリファクタリングをはじめとして、たくさん書籍が出ている。
一方、上記のような書籍に触れるタイミングは個人次第のため、自己流でプログラミングをしている人が圧倒的に多い。
少なくとも、常駐先で色んなプログラマのコードを見てきたけど、10人中、まともなのは1～2人程度で、その他は論外という印象だった。
ここでいう論外とは、例えば以下のようなもの。
1. レガシーコードばかり。
例えば、クラスは使用せず配列を使用したり、変数宣言は全部先頭だったり。
2. 数値のキャストは何も考えずに文字列にしてからパースする。
DBから取得したint型をint.Parse(dbValue.ToString())など。
3. 同じようなコードのメソッド化は考えない。
他にもたくさんあるけど、レガシーコードは必ず見かける。
この手の書き方はソースコードレビューで指摘しても別の箇所で発生し、直らないことが多い。
20代の頃から意識して、よい書き方を考えていかないと、どうにもならない。
一方、書籍を読むのが面倒な人が多く、そういう人には、何かきっかけを与えたい。
ということで実際に業務で遭遇した例を元に、どう書くか定期的に挙げる予定。
意見をいただけるとありがたい。コードは別の記事に。
いろいろな意見をいただいた上でのまとめ 2017/09/10 追記
この記事をきっかけに、様々な方に意見をいただいた。それらを踏まえた上でどうするべきかをまとめてみた。
コーディング規約が守れない場合の対処
規約が守れないプログラマが多数のプロジェクトの場合、規約からはずすことも検討する。例えばbool型の変数名について、「名詞句や形容詞句などを使用すると読みやすい。」という主観的な規約は馴染みの無いプログラマが守るのは困難である。
この規約を守ることに時間を費やすよりは、そもそも別の重要なことに時間を割きたい。
結局、プロジェクトとして守るべき規約なのか、一般的に守るべき規約なのかが重要だと思う。
実装にばらつきが出るような処理のコードについて
実装者によってばらつきが出るようなコードが存在する。ややこしい条件分岐が良い例。
このような場合、実装方法をコーディング規約で強制するのではなく、管理テーブルを使用した共通処理化を行うなど、そもそも実装させないことを考える方が効果的である。
基本設計の段階で実装難易度は見えてくるはずなので、難易度が高い部分を洗い出し、共通処理化などに時間を割いた方が良い。
「良いコード書くきっかけを与えたい」の記事について
どういう実装をするべきかを考える点では使用できるが、あくまで各プログラマにきっかけを与えるにとどめる。
私の場合、どちらかと言えばコメントいただく内容の方が記事の趣旨からずれるとしても重要だったりする。そういう意味で、自分のコードを見直すきっかけになっている。