命名規則に関する定石を知っておく

前回、名前を付けることの大切さや意味について書いたが、今回は実際に名前を付ける際、予め頭に入れておくと良い定石をまとめる。

前例に倣って名前を付けることで、同じようなものは同じようなものとして見てもらえるし、他のメンバとの共通理解も作りやすい。あんまり「自分で考えてオリジナルな名前を付けること」に価値はなく、かえって「自分しか分からないモノ」になってしまう恐れがある。

かといって何も考えずにコピペすれば良いワケではなく、自分が作っている目の前のクラスや変数に対して、どの前例を組み合わせるのが適切か判断する、応用力が問われる。

目次

• よくある命名
• アンチパターン
• 場合別
• 何度でも確認する

よくある命名

よく使われる単語を知っておく。

• 参考 : Javaクラス名ランキング - Qiita
• 参考 : クラス名からリリースノートまで、英語で迷わないために参考にできるサイト一覧 - Qiita
• 参考 : うまくメソッド名を付けるための参考情報 - Qiita
  • Boolean を返すメソッドには is とか has とかを使う、という定石も意外と知らない人がいたりする。
• 参考 : HTML/CSSのクラス名に迷ったら - Qiita
  • HTML の場合、その要素の見栄えではなく、役割を示す単語をなるべく使いたい。
  • .big という見栄えに依存したクラス名は、仕様変更によって「Big」である必要がなくなるかもしれない。それよりは .warning などのように「重要性」を示すような論理的な名前なら変更に強い。

アンチパターン

付けてはいけない名前を理由から押さえておく。結局はプログラムの可読性・保守性に繋がる。

• 参考 : クラスの命名のアンチパターン - Qiita
  • Info とか Data とかいうクラス名は思考停止している可能性がある。Manager とか Helper とか、責務が広すぎる名前も避けたい。

  • クラス名は単数形にしませう。複数形のクラス名だと変数の名前がややこしいことになります

• 参考 : DELETE_FLAG を付ける前に確認したいこと。 - Qiita
  • DELETE_FLAG という思考停止な命名。まず命名としては IS とかで始めたいし、DB 設計に遡っていくと「それ要るの？」「違う形で考えた方がいいんじゃないの？」という話。

場合別

この場合はどうしようとか。唯一の正解はないものの、チームルール策定の際に参考になるかも。

• 参考 : 画像名について考える - Qiita
  • 画像ファイル名にどんなプレフィックス・サフィックスを付けると管理しやすいか、という視点。
• 参考 : キャメルケースで省略語をどう扱うか - Qiita
  • URL とか ID とか、省略形の単語を Url・Id と書くべきかどうか。
• 参考 : htmlのid属性とclass属性の命名はハイフンかcamelかsnakeか - Qiita
• 参考 : CSSのセレクタ部分(IDやCLASS)にハイフンとか使われるの好きじゃないなー。ボクはあまり好きじゃないなー - latest log
  • スネークケースだと、ダブルクリックでクラス名全体が選択できる、というコーディング作業時の利便性がある。
  • ハイフンケースだと、[att|=val] という CSS の Attribute Selector が使える、という言語仕様に基づいた利便性がある。
  • 個人的にはハイフン推し。

何度でも確認する

今回紹介した記事は特にまとまっている記事をピックアップしたもので、世にはこうした内容を取り扱う記事がごまんとある。

そうした記事は一度知ったつもりになっていても必ず目を通し、新たな発見がないか、これまで仕入れた情報の反論となるような意見がないか、確認しよう。

この業界は、「知ったつもりになって勉強を止めること」が一番の大敵。それまでは正解とされていても、時代の変化によって「誤り」になることも多いし、「トレンド」というものも意識しないといけない。

だから、「それ前に見たわ」とか「この場合はこういうもんでしょ？知ってる知ってる」と思っても、似たような記事を見かけたら必ず目を通しておき、「今年も思ったとおりのことが書いてあった、よかった」とか「あれ、これがアンチパターンと云われるようになってきた、確かにそうだが、でもこういう場合ではまだ有効だよな」とか、判断できるようにしておきたい。