Что случилось с этим подходом?

Question

Новый процесс проверки кода был введен в действие, и теперь моя команда никогда не должна объявлять строку как локальную переменную, или фиксация не будет проходить проверку кода. Теперь мы должны использовать константы.

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

String operationId = "create"; 

Это то, что следует использовать вместо:

private static final String OPERATION_ID = "create"; 

Хотя я полностью согласен использовать константы для строк, которые появляются +2 раза в коде ... Я просто нахожу, что это излишне, чтобы полностью не иметь возможности объявлять строку на месте, если она используется только один раз.

Просто, чтобы убедиться, что это ясно, все они ЗАПРЕЩАЕТСЯ при любых обстоятельствах следующее:

• String div = "div1";
• Catch(Exception ex){ LOGGER.log("csv file is corrupt") }

• Объединение строк String str = "something ...." + someVar + "something" ... мы должны заменить someVar с %s, объявить все как глобальную строку, а затем использовать String.format(....)

• if(name.equals("Audi"){....}

• String value = map.get("key")

Любые идеи, ребята? Мне нужны веские аргументы. Я готов принять любую позицию, подкрепленную хорошим аргументом.

Спасибо.

Answer 1

Прежде всего, давайте вышлем ваше предположение: нет ничего изначально неправильный с описанным подходом.

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

private static final String OPERATION_ID = "create"; 

Действительно, это не используется где-нибудь еще? Ничего не сломалось бы, если бы я изменил это на строку «beetlejuice»? Если что-то сломается, то что-то еще использует эту константу ... Если «что-то еще» оказывается кодовой базой на другом языке, и поэтому они не разделяют строковые константы - это исключение, а не правило , Консистенция!

---

Тем не менее, есть несколько вещей, которые я бы стандартизировать в несколько иной манере, но я бы еще унифицировать их, тем не менее:

Я хотел бы предложить что позволяет строковые литералы в конструкторах перечислений:

public enum Operation { 
    CREATE("create"), 
    ... 
} 

потому что здесь перечисление - это константа, на которую ссылаются в коде, а не на строковый литерал. Объявление константы как перечисления или как private static final String эквивалентно мне, и нет необходимости делать то и другое.

Кроме того, я бы не использовал этот шаблон нигде, чтобы он нарушил способность вашей среды IDE предупреждать вас о недостающих строках - например, поиск строк из файлов .properties. Многие IDE дадут вам правильные предупреждения при поиске ключа в файле .properties, которого не существует, но дополнительный уровень косвенности может нарушить это, в зависимости от того, насколько разумна ваша среда IDE.

Catch(Exception ex){ LOGGER.log("csv file is corrupt") } 

Это для меня небольшая область - это сообщение только для внутреннего использования? Являются ли журналы только когда-либо видимыми вами, разработчиком, или они тоже полезны для пользователя?

Если это только для разработчиков приложения, они, вероятно, не нуждаются в локализации.

Если вы ожидаете, что пользователь просмотрит журналы, они должны быть выведены из внешнего вида в файл .properties.

Answer 2

Это хороший стиль кодирования для определения константы для значения/литерала, когда значение/литерал используется несколько раз.

Наложенный стиль кодирования заставляет использовать константу для каждые строковый литерал.

good Эффект этого стиля кодирования: все строковые литералы, которые действительно должны быть объявлены как константы, теперь объявляются как константы.

Плохой Значение этого стиля кодирования: Вы - разработчики - не можете решить, должен ли строковый литерал быть определен как постоянный или нет. Это тяжелый удар.

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