プログラミングする上で避けるべき命名パターン

この記事は ただの集団 AdventCalendar PtW.2019 (https://gw-advent.9wick.com/calendars/21) の4日目の記事です。
前日は erika 様の AWS GlueでETL - Qiita でした。

はじめに

きれいな変数名、クラス名、メソッド名つけれていますか?

出来ていない理由の大半に、

  • すでにある名前に合わせている
  • 複雑なことをしていて、適切に名前を考えられない

などがあると思いますが、ここではそういった構造や歴史的経緯などは取り扱いません。
単純に見かけた瞬間、「やばい?」という感覚を持ってもらいたいだけです。

ここで言いたいことは、 以下のようなパターンの名前が出てきたら大抵の場合、何かがおかしい可能性があるのでコードを見直しませんか? という問題提起です。 ヒヤリハットだったり、気付きの一助になれば幸いです。
プログラミング言語として、Webアプリケーションでよく使われるような言語を対象にしています。

あと、適当にパターンとかつけていますが特に分類したわけではないし、個人的な考えにすぎないのであまりツッコミしないでください。

略語パターン

標準(だと書いた人が思っている)略語パターン

  • tmp
  • ret
  • fmt
  • frm
  • cd
  • cvt
  • cmn

やたらと3文字に納めようとしているパターンです。
おそらく書いた人は標準で、よく使われていると思っています。 しかし、残念ながら通じていないことのほうが多いので気をつけたほうが良いです。

こういった単語が出てきた場合、 x, y, z や m, n などに置き換えてもコードが読めるかどうか考えてみましょう。
通じない場合、この命名自体が間違っています。
通じる場合、そもそも意味を持っていないので、 a, b, c などで置き換えてもとの単語を考えさせないようにしましょう。

母音省略パターン

  • kbn
  • kss
  • bbr
  • nyknb
  • 例はいくらでもあるので省略

もはや、なんのことか一見しただけでは意味不明なパターンです。
DBのカラム名などでよく発見されます。
8文字以内に収めようとして母音の一部だけ省略している亜種がある場合もあります。

いかなる場合においても許されない(と自分は考えています。異論は認めます)
たとえファイルサイズやメモリサイズを削りたい場合においても、意味をなしていないので省略したいなあらいっその事全く意味をなさない文字の方がまだマシです。
何らかの意味を持っているのではないか?業界特有の略語があるのではないか?など余計な考えを発生させてしまうことが良くないと思います。

数字Suffixパターン

  • xxxx1
  • xxxx2

など後ろに数字がついており、かつ数字以外の名前が一致しているパターンです。
メソッド内の変数名の場合、多分順次処理を一時変数に置き換えているのでしょうが、時々使う順番を変えていたりするので読む側に混乱を招きます。
メソッド名そのものの場合、もはや使い分け方法は他人には理解不能になります。
オーバーロードのように、同名のメソッドを型で区別する方法があるのでそういった手法を取る、位なことをしましょう。
そもそも処理ごと違っており同名をつけるべきでない場合もあるので、 気をつけたいパターンです。

文章パターン

  • fooAndBarAndBazAnd...
  • doHogeThenDoFugaAnd...

やたらと長い変数名やメソッド名がある場合、よく読むと文章や複数の小節から構成されているときがあります(例外としてテスココード中の変数名・メソッド名は除きます)
責務を適切に分離できていない場合、こういったパターンが見受けられます。
このパターンは上記までのパターンに比べ、リファクタリングのチャンスだ、というポジティブに捉えることができます。
And, Or, Then, などが変数名・メソッド名に含まれているのがよくある特徴です。

おそらくメソッドが長い、特定処理に対して適切なドメインを導き出せていない、など改善できそうな事が多いので、積極的に見つけた箇所のリファクタリングを推進すると良いと考えます。
その際に、 コードの臭い - Wikipedia を探すのが良い対処方法になるかもしれません。

英語がわかんないよパターン

動詞と名詞がおかしいパターン

  • クラス名に CreateUser
  • メソッド名に UserCreate

日本人だからね・・・仕方ないね・・・
で、終わればよいのですがおそらく周りのコードに流されて惰性で何も考えずにつけられている事が多いです。
この場合、適切にクラスやメソッドが作られているとは言えないことが多いです。
名前そのものがヤバイ、というよりこの名前が残ってしまっているとおそらくコードにも何らかの問題があると推測される方がヤバイです。

ハイブリッドパターン

  • createRiyousha
  • sakujoUser

みたいなパターンです。 日本人だからね・・・(ry
では済まないことが多いです。
こちらの場合、動詞や名詞がおかしいパターンよりも深刻な場合があります。
おそらく、他のクラスや他のパッケージに同じ意味を示すような変数名が複数存在している可能性が高いです。
ユビキタス言語がなく、開発者が好き勝手に名前を考えてつけたけど、命名方法は個人の裁量に任された結果発生している可能性が高いです。
今すぐにでも開発者全員集めてドメインモデルをみんなで考えて見ることをおすすめします。

英語で統一されていてもユビキタス言語がない場合もありますが、これは別の問題なので今回取り扱いません。

コメントで言い訳しているパターン

// 本当は○○だが、その後△△△する必要があるため、一旦□□する
val savedFileTemp1 = ...

はい。
時間がなく、ひどいコードやひどい名前であることを実装者は知っています。
これを見た人がマネージャーなりリーダーなら、今すぐリファクタリングのタスクを作り本人に是正することをお願いしましょう。同時に「無理させてゴメンね」と優しく声をかけましょう。
マネージャーなのか、リーダーなのか、はたまたプロダクトマネージャーなのかわかりませんが、無理のあるスケジュールや他人が決めた納期という謎の概念によって書いた人は苦渋の選択でこういったコメントを残しています。
変数名とは離れましたが、ひどい変数名になっていたとしてもこういったコードになった原因は違うところにある場合が多いです。

避け方としては、 常にリファクタリングしたりコードを見直す時間も考えていくしかありません。

まとめ

つらつらと書きましたが、こういったパターンに陥らないためには

  • プログラム上で使う名前を考える時間は、コードを書く時間の7割を注ぎ込んでも良い

と思うくらいには大事です。 一番時間をかけても良いと思います。
うまい変数名、メソッド名が考えられない、ということは責務の分離が必要だったり、コードそのものや設計そのものを見直すきっかけになります。
納期が・・・という言葉に惑わされない強い心と、ときには組織の仕組みの改善が必要になったりしますが、それはまたの機会に・・・