http://www.zusaar.com/event/438105 これ用

1. めいめいについて考えること
@muo_jp

2. めいめい?
内輪ネタを10枚ほど省略

3. 理想:分かり易く短く+統一感

4. 現実: めいめい好き勝手命名

5. 困ること
良い命名にはそこそこの手間と時間がかかる
手間をかけずにｍ9っ｀Д´) ﾋﾞｼｯ!!と決められるレベ
ルへ到達するのに相当な鍛錬が必要
プロジェクト進行の限られた時間内では軽視されがち

6. 出来ると良いな、命名レビュー
設計/コードレビューの一部としてプロダクト品質評価
の中に「適切な命名が行われているか否か」を含める

7. レビューを行う局面
新規設計時のレビュー
API設計を行う際には、かなり慎重に
構造改善のためのリファクタリング時
機能切り分け変更の為再命名が必要となるケースも

8. リファクタリングの一部としての
命名
マーティン・ファウラーの『リファクタリング』には
そもそも『メソッド名の変更』項目が含まれている
「(略)うまく行う方法は、まずメソッドにどのような
コメントをつけるべきかを考え、次にそれをそのま
まメソッド名にしてしまうことです。」(p.273)
長すぎる明確な名前よりは、短め+Javadocもアリか
注意: 既に当該名での利用者がどの程度居るか?

9. 現実的な優先度付け軸?
当該APIやコードを読む可能性がある人の範囲は?
→チーム内、部署内、社内、国内、世界
当該コードの想定寿命は?
→すぐに捨てる、単発PJ、他PJにも使い回す
コードを書く際どの程度エディタやIDEの支援を受けられるか
IDEがしっかりしてる: C#+VS, Java+Eclipse, JavaScript+VS
言語仕様的に短めの名前+引数名で補足が可能: Objective-C
あんまり期待出来ない: Python, Ruby, PHP