コーディングでこだわってることを書き出してみた
同僚にコーディングのこだわりが聞きたい!と言われたので、思いつくままに書いてみました。
数ヶ月後の自分が困らないコードを書く
分かりやすいコードを書くために意識していることです。
仕事でコーディングしている以上、自分が書いたコードは誰かがメンテすることになります。他の人かもしれないし、未来の自分かもしれない。なので後で困らないよう、極力分かりやすいコードを書く必要があります。でも、他人が分かりやすいかどうかはいくら考えても自分では判断できません。そこで、私は他人でもあり自分でもある未来の自分に向けてコードを書くことにしてます。そしたら自分本位なコードにはならないだろうし、自分本位なコードでなければコードレビューもしやすくなるので、他人にちゃんとみれもらえます。そしてそこから得たフィードバックを自分のコードに反映すれば他人にとっても分かりやすいコードになります。
あと、自分の記憶力をあてにしてないとうのもあります。
人はどんなに意識してても忘れるので、忘れる前提で動いたほうが楽だと思ってます。覚えておく必要があるものが少ないほうが、今の自分の仕事に安心して取り組める気がします。
具体的にどのようにコード書いてるか以下のとおりです。そんな特別なことをしてるつもりはなくて、当たり前のことを当たり前にやるのが重要かなと思ってます。
- 名前を適切に
- 嘘はつかない
- 馴染みのない英単語をつかわない
- マジックナンバー
- 変数化
- ↑が難しいならコメント
- 条件分岐やループのネストを避ける
- 重複を避ける
- 1つの変更で2箇所修正したくない
- インデント
- ルールに従う
- コメント
- ドキュメンテーションツールのフォーマットに従って関数、クラスにコメントを書く
- わかりにくいところだけ
- getterとかsetterは見ればわかるので必要ない
- ドキュメントもメンテが必要なので、極力書かないほうがよい
- わかりにくいところだけ
- 忘れたら後で苦労しそうなことはコメントを残す
- ドキュメンテーションツールのフォーマットに従って関数、クラスにコメントを書く
- コミットログ
- 概要、Why
- issueやチケットと紐付けて、何の機能開発時の変更かわかるように
- 修正時に影響範囲の確認が楽
手を入れる前より綺麗に
前職も現職も息の長いプロダクトの開発をしています。 その経験上、とくに問題が発生しないかぎりがっつりリファクタリングの時間はとれないのが現実です。なので、普段の機能開発でこっそり少しずつやっていくようにしてます。ボーイスカウト・ルール ってやつです。
綺麗にする程度はどんなに小さいことでもよいことにしてます。でないと続けられないので。例えば、変数名を適切なものに変えるだけとか、インデントを整えるだけとかでもOKにしてます。
こうして普段から少しずつ綺麗にするようにすれば、将来的にリファクタリングだけの時間を取らなくて済むかもしれないし、取る必要があったとしても短時間で済むようになるかもしれない。部屋の片付けや掃除と一緒です。
その他細かいこだわり
細かいものを箇条書きで書き出してみました。
環境
- OS
- エディタ
- RubyMine
- がっつりコーディング用
- 補完が優秀
- ⌘ + クリックでジャンプ
- diffが左右(GitHubと同じ)で見やすい
- Sublime Text
- ちょこっとコーディング用
- 軽い
- シンタックスハイライトはダーク系が好き
- Twilightっていうカラーテーマをもう何年もつかってる
- 目に優しそうな気がする
- なんかカッコいい
- フォント
- Mac: Ricty
- Win: Consolasとメイリオをフォントリンク
- RubyMine
- デュアルディスプレイじゃないとツライ
コーディング
- インデントは2スペース
- インデントとりすぎると横に広がりすぎるのがツライ
- インデント1だと見づらい
- 1行で書けるなら1行で書く
- ただし、可読性が悪くなる時はやらない
- 三項演算子のネストとか
- 1行が長くなる時とか
- コーディング規約的に推奨されてない時ももちろんやらない
- ただし、可読性が悪くなる時はやらない
- 空行使って分かりやすく
- グループビング
- 処理の切れ目
- andより&&
- 記号だと演算子だとすぐわかる
x and not y and z
よりx && !y && z
のほうが分かりやすいよね
- 色はHexで小文字
- 大文字打ちづらい
- 小文字の方がわかりやすい気がする
その他
- コーディング以外のこともやる
- 勉強する
- 遊ぶ
- 睡眠と栄養をしっかりとる
最後に
こうして書いてみると、こだわりって意外と出てこないですね。多分、自然とやってることだからかなぁと。もしくはそんなにこだわりがないのかもしれないけど。 いずれにせよ、自分で自分の良い点や、こだわりを言語化するのは難しいってことが分かったので、これからは他人のコードを読むときは良い点やくせみたいなのを見つけたらその人に言うようにしようと思います。
環境面のこだわりはもっと色々書けそうなので、別記事にして書こうかな。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本(ソフトカバー)
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (132件) を見る