長いので章ごとにしようと思ったけどできなくて、今回は残り半分で…。
10 名前設計 ーあるべき構造を見破る名前ー
10.5 構造を大きく歪ませてしまう名前
- ありそうな気はしてます…。
10.5.1 データクラスに陥る名前
- 〜Data、〜Infoにロジックを書くのを遠慮しているひと、あんまり見かけはしなかったですが…そう思っちゃうかもしれません。
- DTOなどのことを考えると、逆に参照専用のクラスに〜Dataとか〜Infoをつけよう、というルールを作って、静的解析に追加できればよいのかも？
10.5.2 クラスが巨大化する名前
- ふと、なんでもかんでもいったん〜Managerに実装して、あとから切り出すでもいいんでしょうか…？
- delegateとか使えば案外…？
- なにげに、なんでもかんでもやってしまうマネージャー、あんまりよくないんじゃないですかねえ…。だんだん部下に仕事を渡していかないと…！
Column クソコード動画「Managerクラス」
- 実在とは👼
- どう言ったらちゃんとバラす時間を取ってもらえますかねえ…。
10.5.3 状況によって意味や扱いが異なる名前
- パッケージを分けるというのは、サービスを分割するようなイメージを持ってもいいんでしょうか…？
10.5.4 連番命名
- 仕様書のページに対応してる系ならあるのかも…？
- 変数の命名くらいしか遭遇したことないかも。
10.6 名前的に居場所が不自然なメソッド
10.6.1 「動詞 + 目的語」のメソッド名に注意
- Enemy#addItemToParty ってだいぶ名前がおかしいですね…。
- わからんけど、Partyクラスがあるならそっちへ持って行きたそうです。
- でも、こういうメソッドよくあるし、よい置き場所がみつからないときは自分も結構作ってしまっていますね…。
- クラスを作る習慣がないと…というのはたしかにそうかもしれません。
10.6.2 可能な限り動詞1語で済む名前にする
- 同意。
- 長い名前は…困ったときにつけている印象です。
10.6.3 不適切な居場所のbooleanメソッド
- 英語として読めそうにする、というのは気をつけてます。
10.7 名前の省略
10.7.1 意図がわからなくなる省略
- …長い名前を嫌がるひとは結構いますよね。
- 最近はエディタが助けてくれるから、長い名前でも気にならないと思うんですが…。
- 数年前にやめた人の書いたコードをメンテナンスすることがたびたびあったので、とても実感してます。
- 5行程度の短い関数の中なら、まぁ、いいんじゃないか、とは思いますが…。
- タイトルを読み替えれば、意図がわかるなら省略可、ともいえますかね。
- いやぁ…書いているときにはわかってたからいいけど、3ヶ月後に見たら💦ってこともあるから、やめたほうがいいですよね。
- あのときのは…長かったですね。
- 5行程度の短い関数の中なら、まぁ、いいんじゃないか、とは思いますが…。
10.7.2 基本的に名前は省略しないこと
- 安いストレージ、素早いコンパイル、エディタの補完…省略する理由はかなり少ないと思います…。
10.7.3 そのほか省略をどう判断するか
- rubocopにrescueのeを指摘されるのは…ちょっとつらいかも。
- とはいえ、全体でそのルールをオフにするのはありえないですね。怖すぎます。
