#はじめに
###結論
####読みやすいコードは人によって変わるが、最善は尽くそう。
これが今回、私が調べてみて出した結論です。
人それぞれ読みやすさは変わります。
いくら自分が読みやすいと思ったコードでも相手に伝わらないこともありますし、昨日の自分が書いたコードを読み解くのに時間をかけることがあります。
この記事は、コードを読み解く時間を極力減らしたい・生産性を上げたいという気持ちで調べ、まとめることにしました。
###そもそもなぜ可読性が重要だなと思ったのか
paizaラーニングやポートフォリオ制作をやっていて、いくつか思うところがありました。
- 昨日書いたコードが読めない
- 問題集の回答と自分の回答を比較した時に読みにくい
- 無駄な工程がある
- コードをもっと簡略化できないかな
エンジニアにとって綺麗なコードを書くこと、すなわちコードの可読性は、生産性の観点で大事だと考えています。しかし、開発業務ではあまり重要視されていません。
その理由は、コードの可読性が低くてもプログラムは動作するからです。
すでにエンジニアをやっている方々はわかるかもしれませんが、コードが長くても処理速度はほぼ変わらないので、webサイトやアプリの動作には影響がありません。
また、エンジニア個人ではなく、可読性を軽視している企業さんが多いように感じました。
とある企業さんで、字下げをしていないエンジニアの方もいるようです。
テックキャンプ卒業したてほやほやの私の見解では、「読みにくいよりも、綺麗な方がいいよね」程度にしか考えておらず(もはや思ってすらいなかった)、汚く適当なコードを書いていました。
しかし、可読性をあげることはやはり大事なのでは? と、僕の可読性が皆無なポートフォリオを見て思ったので、調べてまとめてみました。
世間の、「動くならそれでいい」は本当にいいのでしょうか?
色々とまとめてみました。
綺麗なコードを書く意味
綺麗なコードを書くメリット
- 機能の拡張や修正がしやすい
どこから修正したらいいのかわからないとか起こりにくいし、新機能を追加しやすくなります。
- コードを素早く理解できる
コードは常に人に見られるものです。
上司や部下・未来の自分・GitHubで世界に公開など。
今の自分がわかるけど「誰か」にはわからないコードを書くこと。これで起きる障害は、軽視できないですね。
- 開発時間の短縮
開発経験がなくネットで拾ってきた言葉を使っているだけですが、コードを読み解く時間を除けば大幅な開発の短縮ができると思います。
- 再利用がしやすい
以前、オブジェクト指向についてLT(短いプレゼンテーション)をするところで傍聴しましたが、再利用できるコードが一番いいとおっしゃってました。
メソッドやクラスなど、どういう役割を持たせるか。それをどういう使い方で再利用するか。ここで開発スピードは大きく変わってくると思います。
- コミュニケーションのコストを下げる
綺麗なコードを書くことで無駄なコミュニケーションを減らすことができます。
これによって開発スピードが変わりますし、意見の食い違いなど起きにくい環境になると思います。
以上の5点が挙げました。
開発するに際、綺麗なコードを書くだけでこれだけのメリットを与えてくれます。
#読みにくいコードの要因と対策
メリットは分かったけど、読みにくいコードの定義って? と、僕は思いました。
どんなコードを書いたら、読みにくいのでしょうか?
##読みにくい要因
- コードが長すぎる
- 条件式が長すぎる
- ネストが深すぎる
- 変数名やメソッド名が不適切
- コメントが不適切・ノーコメント
- 無駄な否定系(!=)が多い
読みにくい要因としてこれだけ挙げられます。
###可読性の低いコードのせいで起きる弊害って?
- プログラムを読む時間がかかる
- バグが混入しやすくなる
- バグの原因特定に時間がかかる
- 改修に時間がかかる
また、無駄な伝達など増えて開発が遅れる可能性があります。
今の自分がこれをしていないか、考えるべきですね。
ちなみは私はほぼ全部やらかしてます。(ポートフォリオでよかった・・・)
#読みやすくする方法
可読性が重要なことは理解できましたね。
それでは、どうしたら読みやすくなるのでしょうか?
####綺麗なコードを書くためには
短く三つにまとめました。
- 命名規則を遵守
- 無駄のないコメント
- ネストを深くしない
一つ注意点があります。
コメントはコードを書き換えた際に変えてください。
いくらコードが読めるとはいえ、コメントが違うと混乱してしまいます。
以上でコードの可読性についてお話ししました。
今のポートフォリオから可読性を高める行動をとっていきたいと思います。
#参考文献・動画
リーダブルコード
YouTube
記事
https://el.jibun.atmarkit.co.jp/daisukekasuya/2012/08/post-34fd.html