Константы и ремонтопригодность

Question

У меня есть простой вопрос, который относится к хорошей практике программирования. В частности, мне любопытно, как правильно обрабатывать константы группировки. В школе они учили нас размещать наши константы в начале файла, в котором они объявлены вначале (обычно это файл класса, и у профессора есть некоторые различия). Теперь я видел в нескольких местах в отрасли, где ВСЕ константы извлекаются и объединяются в один большой файл типа включения.

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

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

Answer 1

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

• Параметры конфигурации: => вне кода, где это возможно, в файл конфигурации или базу данных.
• Строки интерфейса: =>в файле ресурсов (для простоты обслуживания и локализации).
• Возможно enum s: перечисления прекрасно переносят несколько констант в одном контексте (например, дни недели, состояние подключения ...).Я обычно помещаю определение в тот же пакет, в котором оно используется, или в совместно используемую библиотеку, если его используют несколько сборок / компонентов.
• Глобальные / статические объекты: я проверяю свой дизайн, чтобы увидеть, если singleton или *Можно применять шаблоны 1012 * (или зарегистрировать объект в DI framework).
• Тестовые ожидания: я обычно оставляю их такими, какие они есть в тестовом методе, для удобочитаемости.
• «Магические» числа: мне редко приходится ими пользоваться;возможно, оставит их в семантически связанном классе.

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

По той же причине помещать все константы в один большой файл плохо.Допустим, одна из ваших сборок зависит только от константы X. Эта сборка должна быть перекомпилирована, даже если константа Y изменяется, и это изменение должно не повлиять на нее.

Answer 2

Чтобы дать слишком упрощенный ответ, я считаю, что лучше размещать их там, где вы ожидаете их найти. Смысл, классифицировать их. Это относится к принципу сцепления . Преимущества этого в том, что вы найдете их легче, когда они вам нужны. Вы можете легко включить только нужные вам константы, не загрязняя пространство имен другими неиспользуемыми.

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