技術とか戦略とか

SIerで証券レガシーシステムを8年いじってからSESに転職した業務系エンジニアによる技術ブログ。

コーディング規約の重要性と無い場合の対処

ソースコードを書く上で、好みの書き方は個人によってある程度分かれてくると思います。
例えば、if文で定数を右辺に書くか左辺に書くかは、人によって好みが分かれます。
 
・右辺に書く例
 if (value == 9) {
 
・左辺に書く例
 if (9 == value) {
 
左辺に書く方法は「ヨーダ記法」と呼ばれ、「==」を誤って「=」と書いてしまった時に、代入が行われて処理が継続するのではなく、異常終了でミスを知らせてくれる、というメリットがあります。
しかし、入門者向けの書籍では右辺に定数を書く場合が多いので、左辺に書く方法の方が見慣れていて馴染みやすい、という方も少なくありません。
 
どちらの書き方にも良い点と悪い点があり、どちらが良いかは一概に言えません。
 
----
 
しかし、ソースコードの書き方で、明らかに悪い書き方があります。
それは、箇所によって書き方が混在した書き方です。
一人でソースコードを書いている場合は書き方が混在することは少ないのですが、複数人で開発している場合は書き方が混在することが良くあります。
 
人がソースコードを読む際は、ソースコードの書き方から、記述内容をある程度予測して効率良く読もうとします。
ここで、書き方が混在していると、記述内容の予測を誤り、分析ミスや改修ミスに繋がりかねません。
 
先の例で言うと、if文の定数が右辺に書かれている箇所と左辺に書かれている箇所が混在している場合、定数値と変数値を逆に読んでしまう可能性があります。
これは、分析ミスや改修ミスに繋がりかねません。
注意深く読めば読み誤りは防げますが、ソースコードを読む時にストレスを感じるでしょう。
 
ソースコードを効率良く読めるようにするために、書き方を統一することは重要です。
少なくとも、一つのソースファイル中では書き方を統一するのが望ましいです。
 
----
 
コーディング規約が存在している現場であれば、ソースコードの書き方が統一されやすくなります。
しかし、コーディング規約が存在していない現場もありますし、存在していたとしても規約が十分に網羅的でなかったり、規約が読まれなかったりすることもあります。
 
コーディング規約に頼れない場合は、周りのソースコードの書き方を真似る、というのが良い手になることが多いです。
先輩社員からソースコードの書き方を真似るように言われた人も少なくないと思いますが、そのように言われる理由の一つが統一性の確保です。
 
しかし、全く新しいプロダクトを作成する場合はソースコードの書き方を真似ることができませんし、真似るべきではない書き方というのも中にはあります。
ソースコードの書き方を真似られない場合の対処や、真似るべきではない書き方の判断のためには、一般的に良いとされるソースコードの書き方を覚えるのが良いです。
書籍のサンプルコードは一般的に良いとされるソースコードの書き方がされていますし、良いソースコードの書き方を解説した書籍も存在します。
また、言語によってはコーディング規約が公開されている場合もあるので、その場合はそれを参考にできます。
例えば、C#Microsoft社が公式にコーディング規約(https://docs.microsoft.com/ja-jp/dotnet/csharp/fundamentals/coding-style/coding-conventions)を公開していますし、JavaScriptWordPress社がコーディング規約(https://ja.wordpress.org/team/handbook/coding-standards/wordpress-coding-standards/javascript/)を公開しています。