この記事はプログラミングの実務経験と『リーダブルコード』を照らし合わせ、
これだけは抑えておきたいと思った項目をピックアップしています。
抑えておきたいこと
他人が理解しやすいコードを書く
常に「他人が理解しやすいコード」を意識する。
これは１章に書いており、本書の核となっています。
他章はこの核をもとに、具体的な事例に落とし込んでいます。
「他人が理解しやすいコード」は、プログラミングをする上で最も重要であり、意識し続ける必要があります。
名前に情報を詰め込む
見ただけで処理の内容が伝わるよう意識します。
１度決めた名前は後から中々変えづらいため、慎重に命名する必要があります。
また、プロジェクトが進むにつれて、追加機能や機能変更が発生することがあります。
Ex.)ボールを蹴るメソッド
→shoot?pass?kick?
Ex.)サッカーボールだけでなくラグビーボールも蹴れるようにしたい（追加開発）
→kickBallに決めてたのに、、、
このような場合は、以下のような対策をしてください
・開発チームに命名規則を伝える
・configに書く
・クラスやメソッドにコメントを書く
など。
余裕があればリファクタリングしてください。
インシデントを整えることで可読性が増す
インシデントルールがメンバによって異なる場合、可読性が落ちます。
エディタを活用し、インシデントを整理してからgitに上げるようにしましょう。
スネークケースとキャメルケース
本書には載っていない項目です。
どちらを利用するかはプロジェクトによると思います。（あるいは言語ごとの慣習がある）
私がやっているLaravelでの開発では、キャメルケースを基本としています。
複雑な処理についてはコメントを入れる
読み手が質問しそうなことを考えます。
・処理の内容
・経緯
・欠陥
・自分の考え
全てを書く必要はありません。（コードですぐにわかることは書かない）
ループと条件式の単純化
ネストが深くなるにつれ可読性が落ちます。
私のプロジェクトでは2階層までとしています。
複雑な条件式を無理やり１行まとめると、可読性が落ちます。
（正直、三項演算子は読みにくい）
ケースバイケースですが、初心者にもわかるように意識してほしいです。
感想
リーダブルコードは全てのビジネス文書に通づる。
最初に書いた「他人が理解しやすいコードを書く」は、ビジネスにおけるメールやドキュメントにも言えることです。
リモートワークが増えた今、文章は「能力や性格」を表現するものとなっています。
読みにくい、誤字が多い、というだけで評価が下がることもあります。
逆にいうと、伝わる文章を書くだけで、評価が上がり、ビジネスが円滑に進んで行きます。
それだけ重要あり、ビジネスの基本なのです。
動くのは当たり前
疲れていたり、納期が迫っていたりすると、
動けばいいや〜と思いがちです。
ですが、プロとして、
「動くのは当たり前」という心構えを常に持つことが重要だと思います。