はじめに

こんなタイトルで書いていますが、
私自身、命名なんてどーでも良いと思っていました。
（正直動けば良いので過去形では無く今も思っている「かも」）

キャメルケースにしろだとか、メソッドは動詞で書けだとか、
そんな規約は色々書かれている方はいます。

しかし、それ以前の所で、
「この名前の付け方は無いだろ。。。。」
って、思うことがしばしばあるので、
自分には名前の拘りがあるかと最近思うようになったりならなかったり、、、

ガイドラインにアンチパターンを書いておけば、
とりあえず許されざる名前が増えることは防げるのかな？っと思い
この表題で4年ぶりに執筆します。

最初に言った通りこう命名しろって拘りがあまり無いので、
この命名は止めてと欲しいアンチパターンの規約となります。

こんな事、記事にする人は居ないよな～っとも思ってたりします。

そも、命名とは？

命名は名前を付ける事です。
名前とは何か考えて付ける必要があります。
wikipedia抜粋の名前の一般論は下記

すべての事象には名がある。我々は先ずその対象に名前を付ける。
そのためには対象の概念を明確にし、またそれ以外の事象との区別を持たなければならない。
この過程で名前を付けた対象が明確になる。

つまり、名前たる条件は
「対象の概念を明確にする。」
「それ以外の事象との区別する。」
の2点が必要なんじゃないかな？
っと、私は思います。

ただ、凄まじく詳細な説明チックに書いても、
上記2点の条件は満たしてしまうので、
＋Simpleにする事を追加して。

私的なルールでは
1. 対象の概念を明確にする。
2. 同一名前空間内で他と区別する。
3. 単純にする。

の３つを守れば良いと思います。

命名アンチパターン

以下私が「無いだろ」って思った名前のパターンと即興で考えた例と理由です。

名前に取りうる状態を持たせる

例：「エラー・ワーニング区分」
子供の名前にピアニスト太郎って付けるようなものです。
ピアニスト以外の道が許されないと思いませんか？
エラーと警告以外の状態が増えたらどうするんだよ、、、っと思ってたら、
案の定、インフォメーションの状態が増えました。

概念が明確になっていないってのと、
エラーと警告なんて汎用的すぎて重複する可能性も高いので、
区別されない可能性が高いです。

情報が重複している

例：「商品カテゴリー種別区分」
子供の名前にエクセル秀一って付けるようなものです。
って、秀でた人に育って欲しい気持ち重々は解りますので、
名前の例はあまり響かないですね、、、、

商品種別区分っで良いのでは？
（区分は命名規約で一律付けるサフィックス）
あとできれば商品のなんの種別かを付けるのが良いと思いますが、
種別だと、見る観点が変わると重複する可能性があります。

自明の情報が付与されている

例：テーブル名に「商品情報マスタ」
例：機能名に「商品登録処理機能」
（マスタと機能は命名規約で一律付けるサフィックス）
子供の名前に人間太郎と付けるようなものです。
人間は解ってますから、、、、

テーブルに情報以外入りますか？
処理しない機能ってありますか？
例外はあるかもしれませんが、
こういった所を削ってシンプルな名前にした方が良いかと思います。

汎用的過ぎる

例：「状態区分」
子供の名前ネタ尽きた。。。。。

これが全ての機能で同じものを使うのなら解りますが、
特定の機能だけだったのですよね。。。
また、テーブル内、機能内に閉じているリソースであれば許せますが、
全体で使われるような名前空間が広い場合において、
汎用的な情報のみでは重複する可能性が高いです。

さいごに

ざっと書きましたが、
子供の名前を例にしたのは、
「子供の名前を付けるときくらいに魂込めて付けろ！」
って、誰かが言っていたのを思い出したのが切っ掛け。

大げさな話ですが、
成果物は後の世に残りますから、慎重に命名した方がいいとおもいます。

とは言え、
最初に言いましたが私は名前に拘りないので、

1. 対象の概念を明確にする。
2. 同一名前空間内で他と区別する。
3. 単純にする。

３つを守れば良いと思います。