LoginSignup
0
0

はじめに

Hubbleでバックエンドエンジニアをしている @power3812 です。オブジェクト指向大好きマンで、神クラスを作れないかと模索の日々です:innocent:

今回は今までの経験上アンチパターンだと感じる変数名やクラス名、メソッド名(関数名)について書こうと思います!

特定の言語、設計によってはアンチパターンではない場合があるので、一般論として書きます。

変数名

xxx_info, yyy_data

コンピュータ上で扱っている以上、すべてのプログラムはinfo、information(情報)、data(数値情報)なので、変数名上つけても意味がない単語になっています。

xxx_array, yyy_string

型情報を書くこと自体は悪くはない(個人的には推奨しない)ですが、それならばそのPJのすべての変数に型情報を書くべきです。この変数は型情報を書くが、この変数には型情報書かないだと個人個人の判断になってこの変数に特別な意味があるのかと邪推してしまい冗長になります。

target_xxx, result_yyy

target、resultのような意味の範囲が多すぎる単語(意味がありそうで意味のない単語)を使用すると、スコープが長い場合、なんのtarget、resultかわからなくなります。
targetであればdo_update_xxx、resultであればupdated_yyyなど施すべき処理や施した処理を変数名にして具体例な命名にしましょう。

クラス名

XxxManager, YyyUtil, ZzzProvider

そもそもクラス自体、そのクラスにされた概念(Xxx、Yyy)のManagerでUtil郡なので意味が冗長になるので不要です。
providerもクラス自体、概念(インスタンス、メソッド、定数等)を供給をするものなので意味が冗長なので不要です。

XxxWrapper

使い手側からしたらxxx(目的)が必要なだけで、何かがwrap(手段)されてxxxが提供されていても関係ないです。(手段は関係ない)

メソッド(関数)名

check_xxx

バリデーションなどでよくcheck_xxxなどをよく見ますが、checkだとtrueが返ればokなのか、falseが返ればokなのか、はたまたnullが返ればokなのか分からないのでis_xxxやexsits_yyyなどbooleanで返すようにした方が良いです。

update_and_delete

andが使わるという事は処理が長すぎる可能性があります。updateとdeleteに分割して使い手側がupdateとdeleteを呼ぶべきです。

まとめ

今回は、今まで経験上アンチパターンだと感じる命名についてざっと書いてみました!
オブジェクト指向言語を使っているため、具体と抽象のライン引きが難しいので命名が困ったときに参考になれば嬉しいです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0