#はじめに
###結論
####読みやすいコードは人によって変わるが、最善は尽くそう。

これが今回、私が調べてみて出した結論です。
人それぞれ読みやすさは変わります。
いくら自分が読みやすいと思ったコードでも相手に伝わらないこともありますし、昨日の自分が書いたコードを読み解くのに時間をかけることがあります。
この記事は、コードを読み解く時間を極力減らしたい・生産性を上げたいという気持ちで調べ、まとめることにしました。

###そもそもなぜ可読性が重要だなと思ったのか

paizaラーニングやポートフォリオ制作をやっていて、いくつか思うところがありました。

昨日書いたコードが読めない
問題集の回答と自分の回答を比較した時に読みにくい
無駄な工程がある
コードをもっと簡略化できないかな

エンジニアにとって綺麗なコードを書くこと、すなわちコードの可読性は、生産性の観点で大事だと考えています。しかし、開発業務ではあまり重要視されていません。

その理由は、コードの可読性が低くてもプログラムは動作するからです。
すでにエンジニアをやっている方々はわかるかもしれませんが、コードが長くても処理速度はほぼ変わらないので、webサイトやアプリの動作には影響がありません。
また、エンジニア個人ではなく、可読性を軽視している企業さんが多いように感じました。
とある企業さんで、字下げをしていないエンジニアの方もいるようです。

テックキャンプ卒業したてほやほやの私の見解では、「読みにくいよりも、綺麗な方がいいよね」程度にしか考えておらず（もはや思ってすらいなかった）、汚く適当なコードを書いていました。
しかし、可読性をあげることはやはり大事なのでは？　と、僕の可読性が皆無なポートフォリオを見て思ったので、調べてまとめてみました。

世間の、「動くならそれでいい」は本当にいいのでしょうか？
色々とまとめてみました。

綺麗なコードを書く意味

綺麗なコードを書くメリット

機能の拡張や修正がしやすい

どこから修正したらいいのかわからないとか起こりにくいし、新機能を追加しやすくなります。

コードを素早く理解できる

コードは常に人に見られるものです。
上司や部下・未来の自分・GitHubで世界に公開など。
今の自分がわかるけど「誰か」にはわからないコードを書くこと。これで起きる障害は、軽視できないですね。

開発時間の短縮

開発経験がなくネットで拾ってきた言葉を使っているだけですが、コードを読み解く時間を除けば大幅な開発の短縮ができると思います。

再利用がしやすい

以前、オブジェクト指向についてLT（短いプレゼンテーション）をするところで傍聴しましたが、再利用できるコードが一番いいとおっしゃってました。
メソッドやクラスなど、どういう役割を持たせるか。それをどういう使い方で再利用するか。ここで開発スピードは大きく変わってくると思います。

コミュニケーションのコストを下げる

綺麗なコードを書くことで無駄なコミュニケーションを減らすことができます。
これによって開発スピードが変わりますし、意見の食い違いなど起きにくい環境になると思います。

以上の5点が挙げました。
開発するに際、綺麗なコードを書くだけでこれだけのメリットを与えてくれます。

#読みにくいコードの要因と対策
メリットは分かったけど、読みにくいコードの定義って？　と、僕は思いました。
どんなコードを書いたら、読みにくいのでしょうか？

##読みにくい要因

コードが長すぎる
条件式が長すぎる
ネストが深すぎる
変数名やメソッド名が不適切
コメントが不適切・ノーコメント
無駄な否定系(!=)が多い

読みにくい要因としてこれだけ挙げられます。

###可読性の低いコードのせいで起きる弊害って？

プログラムを読む時間がかかる
バグが混入しやすくなる
バグの原因特定に時間がかかる
改修に時間がかかる

また、無駄な伝達など増えて開発が遅れる可能性があります。
今の自分がこれをしていないか、考えるべきですね。
ちなみは私はほぼ全部やらかしてます。（ポートフォリオでよかった・・・）

#読みやすくする方法

可読性が重要なことは理解できましたね。
それでは、どうしたら読みやすくなるのでしょうか？
####綺麗なコードを書くためには
短く三つにまとめました。

命名規則を遵守
無駄のないコメント
ネストを深くしない

一つ注意点があります。
コメントはコードを書き換えた際に変えてください。
いくらコードが読めるとはいえ、コメントが違うと混乱してしまいます。

以上でコードの可読性についてお話ししました。
今のポートフォリオから可読性を高める行動をとっていきたいと思います。

#参考文献・動画

リーダブルコード

YouTube

記事
https://el.jibun.atmarkit.co.jp/daisukekasuya/2012/08/post-34fd.html