c# - 熱心すぎる文字列定数

Question

これは以前にも尋ねられたと思いますが、この例では、定数をこの程度に分離することで他の人がどのような有用性を確認できるかについて興味があります。

public class CoreStringConstants
 {
  // Common strings
  public const string SPACE = " ";
  public const string PERIOD = ".";
  public const string COMMA = ",";
  public const string COLON = ":";
  public const string SEMI_COLON = ";";
  public const string HYPHEN = "-";
  public const string UNDER_SCORE = "_";
  public const string LEFT_BRACKET = "(";
  public const string RIGHT_BRACKET = ")";
    public const string LEFT_SQUARE_BRACKET = "[";
    public const string RIGHT_SQUARE_BRACKET = "]";
    public const string LEFT_CURLY_BRACKET = "{";
    public const string RIGHT_CURLY_BRACKET = "}";
    public const string PIPE = "|";
    public const string CIRCUMFLEX = "^";
    public const string ASTERISK = "*";

... 本当？

これらの種類の文字列定数をコードから分離する利点は本当にありますか?

ASTERISK で使用される文字は、アプリケーションの予測可能な寿命の中でいつ変更されますか?

score 4 · Accepted Answer

実際、これはデメリットだと思います。特に、とにかく文字列リテラルのプールがサポートされているため、利点は控えめに言っても疑わしく、開発者として、このようなコードに初めて遭遇したときに各定数の値を調べる必要があります。

さらに、誰かが次のようなコードを考え出すでしょう。

public const string COLON = "*";

score 2 · Accepted Answer

ASTERISKあなたが提供した例では、あなたが言ったように、常にになるので、定数は役に立ちません*。

それらの実際の目的にちなんで名前を付ける方がはるかに理にかなっています。たとえば、括弧を使用して文字列内の何かをグループ化する場合、次のように記述できます。

public const string GROUP_START = "(";
public const string GROUP_END = ")";

この場合、グループ化文字が明日変更される可能性があるため、意味があります。

score 1 · Accepted Answer

これらの文字列定数を定義する必要がある理由は 1 つも思いつきません。元の作成者は、文字列を 1 回定義することでメモリを節約できると考えていたのかもしれませんが、C# コンパイラは文字列をインターンするのに十分スマートです。(たとえば、同一の文字列定数は、アセンブリの .DATA セクションに 1 回出力されます。)

var space1 = " ";
var space2 = " ";
Console.WriteLine(Object.ReferenceEquals(space1, space2));  // Outputs true

したがって、正直なところ、CoreStringConstants を使用する正当な理由はありません。

score 1 · Accepted Answer

誰かがこれをやりたがる理由はいくつかあります (ただし、この時代にすべての定数を叫ぶ必要はありません!)。ただし、リストした特定の定義に多くの正当な理由があるとは考えにくいです。

異なる文字エンコーディングは、一部の定数が変更される可能性があることを意味する場合があります。はい、特定の文字エンコーディングでは、「アスタリスク」が ASCII の「」と同じではない可能性があります。中国語では、「」よりも別の文字の方が好ましいかもしれません。ありそうですか？そうではないかもしれませんが、これらの値を定数に含めると、リファクタリングが容易になります。
使用状況に応じて、定数を使用すると、コード全体で使用される文字を変更して、リファクタリングを容易にすることができます。ただし、この場合、これらの定数の名前は不適切だと思います (たとえば、中括弧がスコープの開始を表す場合、「中括弧」よりも「開始スコープ」の方が適切な名前であり、使用するシステムを再定義できます (例) 中括弧の代わりに山括弧を使用して、定数の名前が混乱することなくスコープを開始します)
プログラマーは、将来、文字列または文字のいずれかを使用するようにリファクタリングする可能性があると考えた可能性があります。定数を使用することで、この選択は後でリファクタリングしやすくなります。もちろん、それよりも自分のデザインにもっと自信を持つべきです:-)
おそらくプログラマーは、定数によってすべての文字列が重複するのではなく共有されると考えているのでしょう。文字列インターンは、通常、これを不必要な最適化にします。
名前付き定数は、多くの場合、インライン化されたマジック定数よりも意味があり、タイプミスが発生しにくいです。これが、私が考えることができる唯一の「良い」理由です。

score 1 · Accepted Answer

いいえ、これは役に立ちませんが、これは Steve McConnel のCode Completeセクション 12.7 Named Constants のアドバイスから来るかもしれません。具体的に彼は書いています

「安全な」ものであっても、リテラルを避ける次のループで、12 は何を表していると思いますか?

Visual Basic の不明確なコードの例

i = 1 ～ 12 の場合
   profit( i ) = revenue (i ) = expense ( i )
次

NUM_MONTHS_IN_YEARその後、彼は 12 をor に置き換えた方がよいことを後で示しています。from Month_January to Month_Decemener

それはすべてうまくいっていますが、意味があり魔法ではない文字列を使用している場合、アドバイスは例外を作りません。たとえば、SQL 文字列と正規表現、HTML と CSS の文字列には意味があり、その意味はユーザーによく知られている必要があります。

この種のことは、この質問の特定のケースのようです

score 0 · Accepted Answer

それらの周りにプリプロセッサディレクティブがある場合は、ビルドに応じて異なるセットを指定できます。これは、言語に依存しない必要がある大規模なテキスト処理環境で役立ちます(特に、句読点の使用方法が異なる場合)。

score 0 · Accepted Answer

唯一の利点はCoreStringConstants.SPACE、" ". それ以外には、そのようなことをする正当な理由はありません。

ご指摘のとおり、これらのいずれも変更されることはないため、定義を一元化する理由はありません。

ああ、識別子にすべて大文字を使用するのは恐ろしいことです。

c# - 熱心すぎる文字列定数

7 に答える 7

Related

Reference