Когда лучше использовать время для рефакторинга строковых литералов? - PullRequest
1 голос
/ 18 февраля 2009

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

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

Ответы [ 8 ]

5 голосов
/ 18 февраля 2009

Общей вещью, которую стоит рассмотреть, будет i18n . Если вы (или ваши гадости) когда-нибудь захотите продать свой продукт в Мексике или Франции (и т. Д.), Вы по достоинству оцените, чтобы эти строковые литералы не были разбросаны по всей базе кода.

РЕДАКТИРОВАТЬ: я понимаю, что это не отвечает непосредственно на ваш вопрос, поэтому я голосую за некоторые другие ответы: правило три, и тому подобное. Я понимаю, что вы говорите о существующей кодовой базе, поэтому немного поздно говорить о внедрении i18n с самого начала. Это так легко сделать, когда ты в привычке с самого начала.

3 голосов
/ 18 февраля 2009

Мне нравится применять правило трех при рефакторинге. Если это происходит три или более раз, то код необходимо обновить.

1 голос
/ 18 февраля 2009

Я согласен с JMD, просто имейте в виду, что i18n - это не только изменение строк (валюты, пользовательский интерфейс должны быть привязаны к языкам справа налево и т. Д.)

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

1 голос
/ 18 февраля 2009

Хорошо ли использовать мое время для рефакторинга литералов в константы, так как приложение довольно хорошо установлено и работает хорошо?

Нет, тебе лучше оставить все как есть.

Каковы будут долгосрочные выгоды от этого?

Если никто не прикоснется к этому коду, преимуществ не будет.

Однако вы можете избегать добавления новых литералов. Но я бы в значительной степени оставил существование таким, какое они есть.

Вы могли бы, вероятно, перестроить их в свое свободное время, чтобы лучше спать.

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

Наконец, если вам удастся добавить «рефакторинг» в свой список задач, продолжайте !!!

1 голос
/ 18 февраля 2009

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

1) Существует большая степень риска, связанного с строковыми литералами, так как одиночная ошибка обычно может быть обнаружена только во время выполнения. Сниженный риск ошибок времени выполнения является серьезным преимуществом, поскольку они могут вызывать смущение / разочарование.

2) Кроме того, в случае необходимости их изменения, например, когда они используются для ссылки на другую систему (например, имена таблиц, имена серверов и т. Д.), Их может быть очень сложно обновить при изменении этих других системных имен. Централизуйте их, и это тривиальная проблема.

1 голос
/ 18 февраля 2009

Если вы реорганизовали все ваши общие строки, это упрощает их интернационализацию / перевод. Еще проще, если они все находятся в файлах свойств или в любом другом языковом эквиваленте.

1 голос
/ 18 февраля 2009

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

0 голосов
/ 18 февраля 2009

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

...