deepblue-will’s diary

JS、CSS,Ruby、Railsなど仕事や趣味で試した技術系のことを書いていきます。

コーディングでこだわってることを書き出してみた

同僚にコーディングのこだわりが聞きたい!と言われたので、思いつくままに書いてみました。

数ヶ月後の自分が困らないコードを書く

分かりやすいコードを書くために意識していることです。
仕事でコーディングしている以上、自分が書いたコードは誰かがメンテすることになります。他の人かもしれないし、未来の自分かもしれない。なので後で困らないよう、極力分かりやすいコードを書く必要があります。でも、他人が分かりやすいかどうかはいくら考えても自分では判断できません。そこで、私は他人でもあり自分でもある未来の自分に向けてコードを書くことにしてます。そしたら自分本位なコードにはならないだろうし、自分本位なコードでなければコードレビューもしやすくなるので、他人にちゃんとみれもらえます。そしてそこから得たフィードバックを自分のコードに反映すれば他人にとっても分かりやすいコードになります。

あと、自分の記憶力をあてにしてないとうのもあります。
人はどんなに意識してても忘れるので、忘れる前提で動いたほうが楽だと思ってます。覚えておく必要があるものが少ないほうが、今の自分の仕事に安心して取り組める気がします。

具体的にどのようにコード書いてるか以下のとおりです。そんな特別なことをしてるつもりはなくて、当たり前のことを当たり前にやるのが重要かなと思ってます。

  • 名前を適切に
    • 嘘はつかない
    • 馴染みのない英単語をつかわない
  • マジックナンバー
    • 変数化
    • ↑が難しいならコメント
  • 条件分岐やループのネストを避ける
  • 重複を避ける
    • 1つの変更で2箇所修正したくない
  • インデント
    • ルールに従う
  • コメント
    • ドキュメンテーションツールのフォーマットに従って関数、クラスにコメントを書く
      • わかりにくいところだけ
        • getterとかsetterは見ればわかるので必要ない
        • ドキュメントもメンテが必要なので、極力書かないほうがよい
    • 忘れたら後で苦労しそうなことはコメントを残す
  • コミットログ
    • 概要、Why
    • issueやチケットと紐付けて、何の機能開発時の変更かわかるように
      • 修正時に影響範囲の確認が楽

手を入れる前より綺麗に

前職も現職も息の長いプロダクトの開発をしています。 その経験上、とくに問題が発生しないかぎりがっつりリファクタリングの時間はとれないのが現実です。なので、普段の機能開発でこっそり少しずつやっていくようにしてます。ボーイスカウト・ルール ってやつです。
綺麗にする程度はどんなに小さいことでもよいことにしてます。でないと続けられないので。例えば、変数名を適切なものに変えるだけとか、インデントを整えるだけとかでもOKにしてます。
こうして普段から少しずつ綺麗にするようにすれば、将来的にリファクタリングだけの時間を取らなくて済むかもしれないし、取る必要があったとしても短時間で済むようになるかもしれない。部屋の片付けや掃除と一緒です。

その他細かいこだわり

細かいものを箇条書きで書き出してみました。

環境

  • OS
    • Macの方が好きだけどWinでも可
    • Mac
      • capsにcmdを割り当てて
      • トラックパッド!マウスなくても大丈夫
    • Win
      • 無変換と変換に半角/全角を割り当て
      • 横スクロールもできるマウスが好き
  • エディタ
  • デュアルディスプレイじゃないとツライ

コーディング

  • インデントは2スペース
    • インデントとりすぎると横に広がりすぎるのがツライ
    • インデント1だと見づらい
  • 1行で書けるなら1行で書く
    • ただし、可読性が悪くなる時はやらない
    • コーディング規約的に推奨されてない時ももちろんやらない
  • 空行使って分かりやすく
    • グループビング
    • 処理の切れ目
  • andより&&
    • 記号だと演算子だとすぐわかる
    • x and not y and z より x && !y && z のほうが分かりやすいよね
  • 色はHexで小文字
    • 大文字打ちづらい
    • 小文字の方がわかりやすい気がする

その他

  • コーディング以外のこともやる
  • 勉強する
  • 遊ぶ
  • 睡眠と栄養をしっかりとる

最後に

こうして書いてみると、こだわりって意外と出てこないですね。多分、自然とやってることだからかなぁと。もしくはそんなにこだわりがないのかもしれないけど。 いずれにせよ、自分で自分の良い点や、こだわりを言語化するのは難しいってことが分かったので、これからは他人のコードを読むときは良い点やくせみたいなのを見つけたらその人に言うようにしようと思います。

環境面のこだわりはもっと色々書けそうなので、別記事にして書こうかな。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)