##はじめに
エンジニアとして「クソコードだ」って言われると辛いですので、そのために日々いいコードを書けるように努力しています。いいコードの定義人それぞれですが、自分にとって「いいコードは読みやすいコード」になりますので、読みやすいコードを書けるためにちょっとした工夫を紹介したいと思います。
##使う英語を調べる
当然ですがプログラミング言語ほぼ英語になりますし、変数やメソッド名も英語で付けますので、たまに可読性を上げるために英語力の方が問われているではないかって思ったします。命名などをするために自然な英語を使った方がわかりやすいですが、自分英語ネイティブではないので、使おうとする名前は本当に存在しているか、ニュアンス合っているかどうかのを確かめるために毎回ネットで調べています。まず単語自体を調べて、意味と品詞を確認します（よく英語と思ったら実は和製英語とか、動詞として使ってるけど英語だと名詞になっているとかありますので）。あと自分使いたいシナリオで調べて、ネイティブのエンジニアだとみんなどんな名前にしているのを参考しています。
##Ifを使わない
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 を読んでから、If文を使わないようにしています（もちろんBooleanの判別など逆にIf文を使ったほうがわかりやすい場合がありますので、完全に使わないわけではないです）。やはり何かを修正する時、既存のコードへの修正を最小限に済ませたいとみんな自然になりますので、最初からIf文使ってしまうと、ロジックが変わる度にIfに分岐を追加したり,さらにIfの中に条件分岐を入れたり、最終的にネストが深くなって読みづらくなるわけです。
逆にIfを使わない場合、メソッドに分割したり、クラスにまとめたり、他の実現方法を考えないといけなくなります。また処理の流れ（手続き）より本来実現すべきことに注目して考えるようになりましたので、可読性だけではなく、 より適切な実装ができると思います。あとコーティングが上手くなった気がします 。
##メソッド名を決めてから詳細を書く
コーティングし始めた時、とにかく動くものを早く作りたいので、とりあえず処理を一気に書いて、動くことを確認できてからちゃんとした名前をつけたり、リファクターしたりしていました。正直リファクターしたつもりであっても、大体メインな処理の流れを変えずに、すでに書いているコードに合わせて調整するだけなので、最終のコードは処理の流れに合わせて手続きになりがちです。
それで書き方を変えてみました。実装したいものについてどんなメソッドが必要なのか、詳細を書かずに名前（あとScalaで開発していますので戻り値の型も）だけ全部定義します。それでメインな処理を組みます。上手く組めない時や、処理を見てメソッド名に違和感を感じた時は、コードの構造が適切ではないか、メソッドが適切に分割されていないので、最初から定義し直してもう一回組んでみます。メインな処理を上手く組めて、かつメソッド名が正しく自分の役割を表現できているのを確認できてから、各メソッドの詳細を実装します。
Scalaのコードになりますがイメージとしてはこんな感じです↓
このやり方で実装すると、最初からメソッドが実装したいものに合わせて分割されていますので、手続きではなく実装に合った構造にできますし、メインの処理がスッキリになって読みやすくなります。
もしどうしても上手く名前つけられない場合は、実装したい内容をリストアップして文字にみることで大体できるようになります。それでもできない場合はビジネスロジックや仕様にまだ不明確なところがありますのでもう一回確認した方がいいと思います。
##コメントを書かない
正確に言うと、「コメントがなくても意図を伝えられるように」コードを書くことです。まず情報が間違っているや、そもそも情報がないコメントは、読む人を混乱させてしまうので、書かないほうがいいと思っていますし、コメントで正確なメッセージを伝えるのは、コードで正確なメッセージを伝えると同じくらい難しいと思っています。であればコメントなしでコードだけでメッセージを伝えることに集中すれば、（多分）難しさが半分になるはずです。またコードが変わる度にコメントの内容もそれに合わせて更新しないといけないので、更新漏れを防ぐためにも、最初から書かずに全てコードを正にしたほうがいいと思います。
もちろんコメントが必要な場合もあります。コードでどうしても表現できない（「環境の制限でこう実装しないといけなくなったー」とか）、その時はちゃんと意図（WHY）を記載するようにコメント書きます。