18/04/27 21:01:14.39 CAP_USER.net
命名規則に関連するクソコード
クラス名、メソッド名、変数名などのネーミングを誤るとクソコード認定されてしまいます。会社やプロジェクトごとに多少のルールの違いはあるにせよ、どこに行っても漏れなくクソコード認定されてしまうネーミングパターンのご紹介です。
ネーミングが「記号＋番号」
クラス名や変数名はわかりやすい名称にしましょう。ネーミングを見て内容を推測できるようになっていることが重要です。「記号＋番号」ではそれを見るだけでは何のプログラムであるかを推測することは不可能です。
ネーミングに日本語、英語、ローマ字が混在
プロジェクトによってクラス名や変数名のネーミングルールは異なりますので、何がダメだというわけではありませんが、自由すぎるネーミングを行うのはやめましょう。きちんとプロジェクトでルールを統一することは重要です。
またにクラス名や変数名に日本語を使用することは言語仕様上可能とはなっておりますが、アルファベットを使うことが慣習となっていることと、日本語だとIDEの補完機能がうまく機能しないことがあって非効率化の原因となりますので、避けた方が無難です。
ネーミングにスペルミスがある
ネーミングでスペルミスがあると、後でソースコードから文字列で該当箇所を検索する時に検索にヒットせず、改修漏れの原因にもなります。正しいスペルと間違ったスペルが混在していたりするともう最悪です。スペルミスのないように気をつけましょう。
ネーミングに個人名が使われている
ネーミングはプログラムの中身がわかるような名前にするという観点からも、プログラムの中に自分の名前にすることは適切ではないのでやめましょう。
またソースコードレビューの時に思いがけず恥ずかしい思いをすることになるかもしれません。私は新人の時に「yonemura.sh」という名前で自分用に作ったシェルが他社に買い取られることになってしまい、他の会社のエンジニア２０名くらいの前で「よねむらシェルとは・・・」と説明会で大きな声で読み上げるはめになって大変恥ずかしい思いをしたことがあります。
個人で使うプログラムでもプログラムの中身を表した無難なネーミングにしておくことを強くお勧めします。
ネーミングに番号やアルファベットの連番が使われている
クラスや変数のネーミングに、１からの連番やaからの連番を使うと、クラスや変数の中身を推測することが不可能になってしまうのでやめましょう。こういうことをすると後でそのプログラムをメンテナンスする人に、一々プログラムの処理を細かく解析することを強いることとなり、「このクソコード書いたやつまじで氏ね」と言われてしまいますのでやめましょう。
可読性に関連するクソコード
プログラムは後でメンテナンスするためにも、読みやすく書くことが非常に重要です。処理の内容だけ見ると読みやすくても読みにくくても実行される内容は同じかもしれませんが、読みやすいソースコードは改修の工数を下げますし、バグが混入するリスクも下げてくれます。
ネストが異様に深い
ソースコードの中にネストが何重にもなっている箇所があると可読性を下げてしまいます。ネストを何重まで許可するかはプロジェクトによって異なりますが、個人的には３重か４重くらいまでにおさまるようにコーディングするよう心がけていました。
これとセットで「１行の文字数は８０文字まで」みたいなコーディング規約があるとさらにカオスな感じになってきます。ネストが１０階層＋１行８０文字までとか、考えただけでも嫌になりますね。
インデントがずれている
今どきエディタが良い感じにインデントしてくれるのに、まさかインデントがずれているソースコードなんて存在しないと信じたいところですが、昔作られたソースコードだとそういう化石みたいなクソコードにお目にかかることはあるようですね。
カッコの閉じ位置のインデントがズレていたりすると、著しく可読性を下げますし、コードの解析を誤るリスクも増えてしまいます。こういうことをすると漏れなくクソコード認定されてしまうでしょう。
１つのメソッドが異様に長い
たまに１つのメソッドが異様に長いソースコードにお目にかかることがあります。私の個人的な感想だと某国にオフショア開発に出されてウミガメのように日本に帰ってきたソースコードにそういうメソッド分割の概念が消失してしまったかのようなソースコードが多いように思います。
１つのメソッドの長さが数千行にも及ぶような男前なソースコードにバグが混入してしまい、解析及び改修をしなければならなくなった時には絶望するしかありませんね。
以下ソース
URLﾘﾝｸ(axia.co.jp)