Переусердствующие строковые константы

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, изменится в обозримом времени жизни приложения?

Answer 1

На самом деле, я бы посчитал это недостатком.Преимущества сомнительны, если не сказать больше, тем более что в любом случае есть поддержка объединения строковых литералов, и как разработчику я должен был бы искать значение каждой константы, когда впервые сталкиваюсь с таким кодом.1002 * Кроме того, кто-то будет придумать код, который читает

public const string COLON = "*";

Answer 2

В приведенном вами примере константы бесполезны, потому что, как вы сказали, ASTERISK всегда будет *.

Было бы гораздо разумнее называть их в честь их фактическихцель.Например, если вы использовали скобки для группировки чего-либо в ваших строках, вы могли бы написать:

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

В этом случае это имеет смысл, потому что символы группировки могут измениться завтра, скажем,, квадратные скобки.

Answer 3

Нет, это не поможет, но это может прийти из совета в Code Complete Стив Макконнела раздел 12.7 Именованные константы. Конкретно он пишет

Избегайте литералов, даже "безопасных" В следующем цикле, что, по вашему мнению, представляет 12?

Пример нечеткого кода на Visual Basic

Для i = от 1 до 12

   profit( i ) = revenue (i ) = expense ( i )

Далее

Затем он позже показывает, что было бы лучше заменить 12 на NUM_MONTHS_IN_YEAR или сделать from Month_January to Month_Decemener

Это все хорошо, но совет не может сделать исключение для , когда вы используете строку , значение которой и не волшебство. Например, строки SQL и регулярные выражения, а также строки HTML и CSS имеют значение, и значение должно быть хорошо известно пользователю.

Подобные вещи, кажется, являются особым случаем для этого вопроса

Answer 4

Есть несколько причин, почему кто-то может захотеть сделать это (хотя нет необходимости ПОКРЫТЬ все константы в этот день и возраст!).Однако маловероятно, что существует множество хороших причин для перечисленных вами конкретных определений.

• Различные кодировки символов могут означать, что некоторые из констант могут измениться.Да, «возможно», что в конкретной кодировке символов «звездочка» не совпадает с ASCII «».Возможно, в китайском языке другой символ может быть предпочтительнее, чем "".Это вероятно?Ну, возможно, нет ... но наличие этих значений в константах облегчит рефакторинг.

• В зависимости от использования, использование константы позволяет изменять символы, используемые в коде, для упрощениярефакторинг.Однако в этом случае я бы сказал, что эти константы имеют плохое имя (например, если фигурная скобка представляет начало области, «начальная область» будет лучшим именем, чем «фигурная скобка», что позволит вам переопределить вашу систему для использования (например, угловые скобки вместо фигурных скобок для начала области без путаницы с именем константы)

• Программист, возможно, подумал, что он мог бы изменить рефакторинг для использования в будущем либо строк, либо символови, используя константы, этот выбор легче реорганизовать позже.Конечно, нужно иметь больше уверенности в своих проектах, чем это: -)

• Возможно, программист думает, что константы вызовут совместное использование всех строк, а не их дублирование.Интернирование строк обычно делает это ненужной оптимизацией.

• Именованные константы часто более значимы, чем встроенные магические константы, и менее склонны к опечаткам - это единственная «хорошая» причина, которую я могу подуматьиз.

Answer 5

Я не могу придумать ни одной причины, по которой эти строковые константы должны быть определены. Возможно, оригинальный автор думал, что будет определенная экономия памяти, если определить строки один раз, но компилятор C # достаточно умен для интернирования строк. (например, идентичные строковые константы будут выводиться один раз в секцию .DATA сборки.)

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

Так что, честно говоря, нет хорошей причины для CoreStringConstants.

Answer 6

Если содержит директивы препроцессора, вы можете указать их различные наборы в зависимости от вашей сборки. Это было бы полезно в большой среде обработки текста, которая должна быть независимой от языка (особенно в случаях, когда знаки препинания используются по-разному).

Answer 7

Единственным преимуществом будет то, что написание CoreStringConstants.SPACE будет немного понятнее и менее подвержено незаметным опечаткам, чем " ".Кроме этого, на самом деле нет никаких веских причин для того, чтобы делать что-то подобное.

Как вы указали, ни одно из них никогда не изменится, поэтому нет такой причины для централизации определений.

* 1006О, и использование всего верхнего регистра для идентификаторов просто ужасно.