web-dev-qa-db-ja.com

現在の値に関連する定数名はアンチパターンですか？

たとえば、次のような文字列定数があるとします。

const TITLEBAR_MESSAGE="Welcome back, %USERNAME%!";

次のように名前を付けると、より読みやすくなります

const WELCOME_BACK_USERNAME="Welcome back, %USERNAME%!";

文字列コンテキストを確認するためにTITLEBAR_MESSAGEの定義に移動する必要がないので、「TITLEBAR_MESSAGE」が「Welcome back、xxx」に現在マップされていることを覚えておく必要もありません。

文字列を変更すると、名前も変更する必要があるため、保守性が低下します。しかし、コードは書き込みよりも読み取りの方が正しいでしょう？他のチームメンバーが「TITLEBAR」が何であるかを知る必要がないように、後者の命名はより簡単だと思います。

色定数についても同様のケースが表示されます。

const COLOR_SOME_UI=[32,0,0];

私はそう思います：

const COLOR_DEEP_RED=[32,0,0];

他のチームメンバーは "SOME_UI"が何であるかを知る必要がないため、（色が少ししかない場合）より簡単です。だから私の質問は、現在の値に関連する定数名はアンチパターンですか？

coding-stylenaminganti-patternsconstants
3
ocomfd

それは、定数であり、変更される可能性が低いかどうか、またはそれが象徴的または他の何かを表す定数であり、したがって変更される可能性があるかどうかに完全に依存します。

おそらく変更されない定数の例は次のとおりです。

const PI=3.1415926
const RED=[255,0,0]

この場合はそのまま呼び出します。これは、任意の浮動小数点ではなく、PIの値を表します。

象徴的または他の何かを表す定数の例は次のとおりです。

const WELCOME_MESSAGE="welcome.user"
const CONNECT_URL="jdbc:sqlserver://server:1433;databaseName=AdventureWorks"

これはメッセージ自体ではなく、メッセージを検索するためのキーです。後でキーを「user.welcome」と書く方がよいと判断した場合は、プログラムで定数を変更できます。WELCOME_MESSAGEも同様に有効であり、常に名前を変更する必要はありませんsed同じように。

接続URLについても同じことが言えます。プログラム全体で同じですが、valueも将来変更される可能性が非常に高くなります。したがって、これをCONNECT_ADVENTUREWORKSと呼ぶのは誤りです。データベースの名前は変更されない可能性がありますが、名前はその値を反映しているため、やはりベストプラクティスではありません。値が変更されない場合も同様です。それ以外の場合、名前はプログラムでの使用方法に近いものにする必要があります。この場合、それはデータベースへの接続URL（何であれ）であり、このように呼び出す必要があります。

それは常に定数であり、一定ではない定数です。 :)

6
Neil

定数を定義するアイデアは、値自体以外の特定のセマンティックな意味（ヘッダーの色、円周の二乗比など）を値に与えることです。したがって、後で値が変更された場合にのみ変更する必要があります。 1か所にあり、アプリケーションまたはライブラリ全体がこの変更を反映しています。

これを念頭に置いて、定数名をその意味ではなく値にバインドすることは逆効果です。同じ理由でhow関数はwhatの代わりに何かを実行する必要があります。内容を十分に変更する場合は、定数の名前を変更する必要があります。さらに、COLOR_DEEP_REDソースコードでは、それが何であるかはほとんどわかりませんが、COLOR_PRIMARYは、それがスタイルパレットの原色であることを教えてくれます。

それがアンチパターン自体と実際に見なされているかどうかはわかりませんが、定数に値ではなく意味で名前を付ける理由がはっきりとわかります。

1
Jesus Alonso Abad

コンテンツの文字列定数に名前を付けます。

const WELCOME_MESSAGE="Welcome!";
const WELCOME_BACK_MESSAGE="Welcome back!";

ローカライズされた文字列を表示しているときに便利です。

const WELCOME_MESSAGE="Wilkommen!';
const WELCOME_MESSAGE="¡Bienvenida!';

コンテンツの色にも名前を付けます。

const COLOR_DEEP_RED=[32,0,0];
const COLOR_DEEP_BLUE=[0,0,32];

次に、それらの定数を、使用するために名前が付けられた他の定数で参照します。

const TITLE_BAR_BACKGROUND_COLOR=COLOR_DEEP_RED;
const WINDOW_BORDER_COLOR=COLOR_DEEP_BLUE;

このようにして、すべての色の定義と使用法が1か所で定義され、コードベース全体をたどる必要なく操作できます。

それが私にとってうまくいったことです。 YMMV。

0
aridlehoover

私はほとんど定数を持たないSQLサーバーで作業します（常に同じ値を返す関数を定義できます）。

ここでは、名前の細分性はあまりにも細かすぎると思います。アプリケーションでユーザーを歓迎する場所は1つだけであるため、名前付き定数はまったく必要ありません。代わりに、DisplayWelcomeBackDialogなどの名前付きプロシージャが必要です。

定数（および関数、プロシージャ、変数などのその他のもの）は通常、その意味から名前を付ける必要があります。場合によっては、数学定数が非常によく知られているため、略語を使用できることがあります（Pi = 3.1459など）。

0
George Barwood