キレイなソースコードってどんなもの？
「キレイなソースコードを書けと言われるが、曖昧で良くわからない。もう少し具体的な例を知りたい」
他人にソースコードを見せるのってなんだか恥ずかしかったりしませんか？「キレイなコードじゃないし…」と言う方をよく見かけますが、キレイなコードとは何なのか？僕のソフト開発10年分の経験と職場で言われていることを織り交ぜて紹介します。
この記事には次のことを書きました。
- キレイなソースコードについての具体的な例
読みやすく、意味の分かりやすいコードがキレイだと評価される
一行の文字数
横に長いコードは情報量が多くなり、読みにくく、不具合が出やすいため、エディタの端に到達しない程度が良しとされます。pythonだと80文字以内を推奨していますね。
僕の職場では文字数の制限はありませんが、100文字程度で折り返されているものが多い印象です。
改行のルール
一行に複数の文法ブロックを含めないようにします。複数の変数を一行で定義するときにやりがちですね。一行あたりの文字数と同じく、情報量が多くなり、読みにくくなる可能性が高くなるので避けた方がいいです。。
スペースの使い方
算術や論理演算子の前後を空けるために使ったり、前後の行に記述される代入演算子が同じ位置になるように揃える場合にスペースを使うことがあります。言語によってスペースを空けないほうが良いとしているものもありますが、僕のこれまでの経験を振り返ってみると、空けた方が読みやすい場合が多かったですね。
インデントを揃える
僕の周りではインデントは自然と揃えられていくので、具体的な提案はありません。スペースとタブ文字を混ぜてインデントを揃えてしまう時があるので、その点には注意が必要です。
ネストの深さと長さ
ネストは深くするほど可読性が下がっていくので、不具合を作り込まないためにも浅い方がいいですね。何段までならばいいのか？僕は三段までに努めて、それより深いものは修正する方法がないか検討します。スクロールさせなければ、ネスト全体が見渡せないものも修正したほうが良さそうです。
マジックナンバー
よく言われることですが、数値が示す意味や計算過程が分からなくなるため、マジックナンバーは回避した方がよいです。何故この数値なのか、コーディングした本人も半年後には忘れているかもしれないので、由来が分かるようにしたいですね。
変数や関数の名前
たくさんの人が語ってきた事ですが、基本なので僕も書いておきます。長々とした名前になっても正確な表現にしたいですね。関数名は「具体的な動詞+目的語」とするように努めましょう。普段は問題なくても、不具合対策や追加実装時に横着してしまうケースが多いので注意です。
不要なコードの取り扱い
仕様変更や不具合対策などで、一度書いたコードをコメントアウトして、新しいコードを書いている場合がありますが、不要になったコードは迷わず消してしまいましょう。他人が見ても、何故コメントアウトされているのか分かりません。事情を知らない人に余計な迷いを与えてしまうだけになります。
まとめ
キレイなソースコードの具体的な例について、紹介しました。
どんなソースコードがキレイなのか、人によって基準がバラバラですが、経験浅い人でも読めるコードはキレイだと考えても良いのではないでしょうか？
それではまた。
C/C++で組み込み系ソフトウェア開発の仕事を10年以上やっています。怪しげなデジタルガジェットが大好きです。