へっぽこびんぼう野郎のnewbie日記

けろけーろ(´・ω・`)! #vZkt8fc6J

名前とかはGreppability、Googlability、Pluralability、Integrity、Spellability、Verbability、UnFuckability、Vililityなどに気をつけてつけようという話

Greppability

grepのしやすさ

変数名は基本的に長い方がgreppabilityがあがる
f:id:haruharu1:20150520214909p:plain
wc -lは行数カウントである
出力は同じでも別のところで使うものは名前を一緒にしないこと
ID、user、type、nameなど頻繁に出てくるものは可能な限りグローバルな名前にしない
login_ID_with_EmployeeloginIDのようにする。名前からエンティティも推測できて二重にお得

追記:
login_ID_with_Employeeはクソ命名なので、記述を変更しました。
やりたい場合は、これの上位をemployeeと表現して、employee.loginIdのように書くべきでした。
速度を求められない場合や、それほど大量に書かない場合は、基本的にこういう記述の方が良さそうな気がする。
速度を求められた場合にemployeeLoginId = employee.loginIdなどとすると良さそう。

短ければいい時代 is over

うれしいこと

  • リファクタリングのとき便利
  • 新しくプロジェクトに参加した人も、とりあえずgrepすればどこで使われているメソッドなのかなどがわかりやすくなる
  • とりあえずgrepすればやりたいことがわかるようになる
  • 似たような名前の意味取り違いを少なくする




Googlability

ググりやすさ

難しい概念を使った場合、コメントではなるべくそれを端的に説明している専門用語を使っておく
参考にしたものがあればそれで発見したことも書いておく(○○だと××という理由でできない等)

追記:
たとえば
// ここはレッドブラックツリーの実装をちょっとアレンジした感じ
// これはアプリ内のプレゼンテーション層を模している
// ○○でもできるけれど、そう書くと××がボトルネックで遅くなる

うれしいこと

  • ググれる
  • 知識の交換がしやすい




Pluralability

単数形・複数形の区別(単位系の区別)

element、elementsの明確な区別をする
person -> persons -> people -> set_of_people

うれしいこと

  • 単位において誤解が起きにくい
  • 名前を見ればそのクラスの中にどんなものがあるのか予測できる(「set_of_peopleにはpeopleクラスが入ってそう」のような)




Integrity

意味の統一性

stopAllBattles()という名前にしたのであれば、
pauseAllBattles()は作るべきではない。
stopAllBattles()ではなく、endAllBattles()にすると、
pauseAllBattles()が中断停止、endAllBattles()が終了と、わかりやすい

end、pauseの命名は他のクラスでも使うと可読性があがる。
何かものに例えて命名したのであれば、全てそれに関する名前にすること
クラスを横断して、似たロジックには似た名称をつけること

追記:
なぜなら、「似たようなことやってんな」とわかるので。
似たようなことが大量になってきたら抽象クラスこの場合の例:Controllerを作って継承させれば、
気軽に作れるようになる

日本語はなるべく付けないほうがいい。
もし付けるとしたら全て日本語にしないとわけわからなくなるけどそれは無理なので、やっぱり英語にした方がいい。

追記:
意味の統一性の重要さは、
「このクラスには当然こんな感じのメソッドがあるはず。逆にこっちのメソッドがあるのはおかしい」
という当たり前さを匂わせることができるところにある。
「pauseがあるならstartやendに相当するものもあるはずだろう」
→「したがってこのクラスは『音楽プレイヤー』『リモコン』等と挙動が似ている何らかのインターフェイスなはずだ」
→「したがってこれは、データを入れる場所ではなく、Battleを管理するBattlesControllerBattlesManagerのようなものだ」
というのが感覚的にわかるので、「クラス名がBattlePlayerだって!? これはおかしい!!」というようなことに早めに気付けて、日常的にデザインパターンの見直しができることになる。
かなりじゅうよう。

うれしいこと

  • 名前を見るだけでロジックが大体わかるようになる
  • 似たようなメソッドは流し読みできる




Spellability

スペルの正しさ

日本人は激しく苦手な模様。
スペルチェッカを入れると一番間違えにくい。
略してはいけないスペルなどもあるため、可能な限り略さない方がいい。
pasteをpastと略しているひどいコードを見かけたこともある。
スペルミスは見かけたら影響範囲を確認してさっさと直すに限る。
(じゃないとあとでコンパイルエラーやら出まくってウザい困る)

さぁはやく英語を読む作業に戻るんだ

うれしいこと

  • バグが減る(最高に嬉しい)
  • 意味が通るようになる
  • 英単語の語幹を覚えられて結果的に英単語を覚えやすくなる




Verbability

動詞らしさ

関数には動詞を! 関数には動詞を! 関数には動詞を!
基本的にこんぴゅ〜たは、「状態」を、「手続き」を基にあっちゃこっちゃ移動させてるだけなので、
関数には動詞をつけるべき。オブジェクトを主語、インスタンスを補語や目的語として考えるとわかりやすい。

特に動的言語では、状態がより頻繁に動くので、
静的言語ではOppai lolicon = man.isSuckYojo()と書いてあったときに
「なんでboolean型が入りそうなのにOppai型に入っているんだ。これはおかしい!」となるのとは対照的に
lolicon = man.isSuckYojo()と書いてあっても気付けない。

↓こんなかんじで書くとわかりやすい

man = Man()
woman = Woman()
woman.make_up()
if man.isIdiot:
man.love(woman)
print("わろた")

make_up()はメソッドだけど、メソッドも関数なのでもちろん動詞にする

うれしいこと

  • 何か手続きをするのだとはっきりわかる
  • 文章を書くようにしてクラスを作れるのでなるべく頭使わなくてすむ




UnFuckability

汚い言葉で命名しないこと

平易かつ、柔らかい言葉で名前をつける
killなどよく使われているものは別にいいけれど、isFuckとか、thisWorkIsShit()とか名付けない。

追記:
バグでお客さんとかに見つかったときにたいへんなことになる。リソースを無駄に食う。
命名的にはaの方がマシ。

うれしいこと

  • わかりにくさがなくなる




Vilility

Vimをつかって命名すること

うれしいこと

  • Vimがつかえる



現場からは以上です。


追記:
なおこれはオブジェクト指向的な命名のしかたなので、手続き型のときはたぶんもっと違った手法になってくるとおもいます。
手続き型のときは、「手続きが重要」で「似たようなものは関数にする」ので、
オブジェクト指向の、「オブジェクトが重要」で「手続きは各オブジェクトに委譲させるオマケみたいなもん」とは基本的に相容れないのだとおもいます。
だからC言語関数型言語ではこの命名方法は全力で無視したほうがいいかもです。