読みやすいコードを目指して ーリーダブルコードを書くー

みなさんこんにちは。プログラマの水瀧です。
最近は弓と矢で機械をバンバン倒してます。彼女の運動神経が欲しいです。
そういえば、もう社会人２年目に入りましたね。早いです。
・・・頑張ります。

さて、前回書きました通り、リーダブルコードを書く上で大切だなと思ったことを紹介します。
ー＞前回の記事
参考：リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
今回はList.Add()のパフォーマンスについても少し出ていますので、
List.Add()といえばあれか？という考えがある前提とします。
では本編をどうぞ。

無駄なものを削除する
無駄なコードはいわばプログラムのぜい肉です。
例をあげるとキリがないとは思いますが幾つか・・・。
よく見かけるものとしては下記ですかね。

• ほぼ二度と日の目を見ないコメントアウトコード
• LINQ で書ける処理を foreach (for)で書いちゃってるパターン
• 無理にループを回し切ろうとする処理

など、他にもいろいろあるとは思いますが、
大抵はパフォーマンスを無駄に喰っていたり、ソースコードの行数が無駄に多かったりするところに潜んでいます。

こういうコードはただただ見通しが悪くなるだけなのでどんどん排除します。
あと、バージョン管理しておけば遠慮なく削除できますね。

定義位置
もう、言わずもがなな事かもしれませんが、変数などの定義位置は
必要になる箇所の直前で定義すると良いです。むしろそうすべきだと私は思っていますよ？
全てを最初に定義するのはもう古いですね。私自身、学生の時にまれに見かけました。
(読みにくいことこの上なかったです。)

ちなみに最初に定義をしていたのは、
昔々のC言語では最初に定義しないとエラーになる言語仕様があり、その時の時代背景が影響しているのだとか。
ただ、現代のコンパイラではどこで定義してもコンパイルが通るように進化してくれたので
昔ながらの「定義位置の枷」が外れたわけですね。
（正確には今でもエラーになるコンパイラは存在するようですが。）
最初に全てを定義すれば同時に記憶することも増えるので、精神衛生上よくないです。
ダメ。絶対。

下位問題抽出
下位問題と書きましたが、いわゆるメソッド抽出です。
役割に関係のない汎用的に使えるだろうコードブロックは
ユーティリティとして抽出してあげれば処理が分離できますし、見通しもよくなります。
汎用的なものとしては役割とは別の処理を３回コピーしていれば該当すると思っています。
とはいえ私自身なかなかリファクタリングしてあげられていないので心境複雑です・・・。

こういった汎用コードの抽出は後々、別の開発でも使えるし、かつ、開発効率の上昇にも繋がります。

まとめ
今回は無駄の排除、変数やメソッドの定義位置、実践的な問題抽出を紹介しました。
自分自身この辺りの内容は、普段から気をつけるようにしています。
おそらくこの手の内容で陥りやすいのが、自分には読みやすいという点ではないかと思います。
一番有効な改善手段はコードレビューだと思っていますので、不安なコードはいろんな人に見てもらいましょう。
それでは今回はここまで。

---

採用情報

クラウドクリエイティブスタジオではエンジニアの方を絶賛募集中です。

皆さんとともに、是非！良きゲームを作っていきたいと思っております！

採用情報