yewton

とは？

ソフトウェアづくり

• 継承は問題を適切に表現出来る場合に 威力を発揮する
  • 濫用すると 人間の能力を越えた複雑度になりかねない
• インターフェースを介した 依存関係逆転こそがオブジェクト指向の真価
• 問題の大きさを 人間が扱えるサイズに収める ために使う

復習終わり

今日持ち帰って欲しいこと

1. 命名は重要か？
2. 命名 Tips

There are only two hard things in Computer Science:

cache invalidation and naming things.
— Phil Karlton

名前を言えるようになったとたんに、いたる所でそれを見るようになりました
– Robin Williams ノンデザイナーズ・デザインブック

• 名前を知らなければ 知覚することすら出来ない
• 森羅万象、名前を与えることで初めて、それについて考えることが出来るようになる

名前重要

あらゆる機能をデザインする時に、私はその名前にもっともこだわります。プログラマとしてのキャリアの中で、適切な名前をつけることができた機能は成功し、そうでない機能については後で後悔することが多かったように思うからです。
— まつもと ゆきひろ

命名に悩んだら

標準ライブラリや利用している外部ライブラリに、
どのようなクラスが定義されているか？

眺めてみるとよいです。

— CODE COMPLETE 7.3 良いルーチン名

• そのために And がたくさん並ぶようなら 分割を検討する
• 暗黙的な副次作用を持つようなメソッドをそもそも作らない

意味のない 動詞
あいまい な動詞
どっちつかず の動詞
を使わない

• handle, perform, output, process , etc…
• そうは言ってもなんとも名付けがたい、そんなときは 実装自体を疑え
  • メソッドにも 単一責務の原則 は当てはまる
• HogeJob#perform みたいなのは
  • クラス名と組み合わせれば分かるので

• 無理に短くしようとしなくていい
• でもその結果あんまりにも長いなら 実装を疑え

命名に悩んだら

標準ライブラリや利用している外部ライブラリに、
どのようなメソッドが定義されているか？

眺めてみるとよいです。

— CODE COMPLETE 第11章 変数名の力

大切なこと

• 変数が表すものを 完全かつ正確に 説明する
• その変数が表すものを 言葉で表現してみよう
• 解読する必要がない 名前をつけよう

— CODE COMPLETE 11.1.1 名前を付ける時に一番大切なことは

• 方法(how)ではなく モノ(what) を表す

• inputRec employeeData

• stateFlag printerReady

• calVal sum

— CODE COMPLETE 11.1.2 問題志向の名前

• 平均 10〜16文字 が最もデバッグしやすい(1990年のとある研究)
• 厳密に守る必要はないが目安にはなる
• 20文字を超えるようなら 自分を疑う

— CODE COMPLETE 11.1.3 名前の最適な長さ

• スコープが短ければ名前も短くていい
  • ループカウンタなどは i とかでいい
• メンバ変数など スコープが長い、生存期間が長い場合は慎重に命名 する

— CODE COMPLETE 11.1.4 変数名へのスコープの影響

• total, sum, average, max, min , etc.
• 修飾子を最後につけるなど 一貫性を持たせる
  • 変数名のもっとも重要な部分を先頭にする 方針などが考えられる
    • revenue_Total, expenseAverage
• チームで定めましょう

— CODE COMPLETE 11.1.5 計算値による変数名の修飾

命名に悩んだら

標準ライブラリや利用している外部ライブラリに、
どのようなメソッド仮引数が定義されているか？
OSS だったらコードを見てどのような変数が定義されているか？

眺めてみるとよいです。

• それが何をするのか、何を表すのか、まずは 言葉で説明してみる
• 解読 の必要が生じるような命名を避け、 読めば分かる 名前をつけよう
• 悩んだら ライブラリをお手本にしよう

Credit

• sspiehs3 による Pixabay からの画像(ジョシュアツリー)