Чому варто дбати про константи

Цей допис про використання констант у коді: чому це важливо, яку користь дає та як робити це правильно. На жаль, я засвоїв цей урок на власних помилках. Спочатку констант у моєму коді було зовсім мало.

Я майже не замислювався про них. Як і в багатьох проєктах, я активно використовував «магічні рядки»: швидко, зручно, скрізь.

form_data = {
    "name": "Update Operation",
    "to_module": "DeplMgr",
    "to_method": "post_job","
    "op": "update",
    "element_type": "monerod_remote",
    "element": self.monerod,
}

Магічний рядок — це текстовий літерал, записаний безпосередньо у вихідному коді застосунку, який істотно впливає на поведінку чи логіку програми. «Магічним» його називають тому, що читачеві коду не завжди очевидне його призначення: значення та роль рядка ніде явно не визначені й не пояснені.

Етап I — магічні рядки

Спершу я взявся стандартизувати назви констант. Приблизно через вісім годин цього марафону рефакторингу я загруз у питанні, як їх називати. Посидівши перед екраном, навигадувавши поганих назв і вилаявшись про себе, я зробив те, що треба було зробити відразу: взявся за дослідження.

Стандартні назви

Єдиний стандарт іменування констант дуже важливий. Я користуюся таким підходом, і він добре себе зарекомендував. Розділяю константи на три категорії:

Зрештою я зрозумів, що магічні рядки — це погано. А потім настав день розплати (який тривав ще шість годин): 30-годинний марафон рефакторингу. Мета була проста: прибрати магічні рядки й замінити їх константами. Це було виснажливо.

Під кінець почали боліти зап’ястки, і я злякався, що розвивається синдром зап’ясткового каналу. Але виявилося, що я постійно натискав Shift, адже всі константи були великими літерами. Коли перейшов на Caps Lock, стало набагато легше.

form_data = {
    NAME_FIELD: UPDATE_OPERATION_LABEL,
    TO_MODULE_FIELD: DEPLOYMENT_MGR_DEFAULT,
    TO_METHOD_FIELD: POST_JOB_FIELD,
    OP_FIELD: UPDATE_FIELD,
    ELEMENT_TYPE_FIELD: MONEROD_REMOTE_FIELD,
    ELEMENT_FIELD: self.monerod,
}

Проблеми з магічними рядками

Помилки

Помилки легко проникають у код, спричиняють несподівані побічні наслідки й важко відстежуються. Наприклад, в одному місці ви використовуєте p2pool_ver, а в іншому — p2pool_version. Помилки під час виконання може й не бути, але програма поводиться дивно.

Неестетичний код

Як середовище розробки я використовую Visual Studio Code. У ньому є підсвічування синтаксису. Коли ви використовуєте магічні рядки, то не отримуєте всієї користі від можливостей VS Code.

Етап II — розумні групи

Минув час. Я поступово зрозумів, що величезна купа констант — зовсім не кінцева мета. Вони були розкидані по коду, у них було складно орієнтуватися, і вони й далі проникали до логіки застосунку не надто охайним способом. Виявилося, що я просто замінив магічні рядки на магічні константи.

Прогрес, але…

Я розпочав новий рефакторинг: тепер не для усунення магічних рядків, а для групування констант за змістом. Ідея проста: константи повинні жити у власній предметній області, а код застосунку майже ніколи не має звертатися до них безпосередньо.

Підтримка віртуальних класів

Я використовую цей ConstGroup.py. Він дозволяє визначати тип даних константи у файлі констант і зберігати код охайним та зрозумілим.

class MetaConst(type):
    """Metaclass that collects public attributes into a dictionary-like mapping."""
    def __new__(mcs, name, bases, namespace):
        cls = super().__new__(mcs, name, bases, namespace)
        cls._constants = {
            k: v for k, v in namespace.items()
            if not k.startswith("_") and not callable(v)
        }
        return cls

    def __getitem__(cls, key):
        return cls._constants[key]

    def keys(cls):
        return cls._constants.keys()

    def values(cls):
        return cls._constants.values()

    def items(cls):
        return cls._constants.items()

    def __iter__(cls):
        return iter(cls._constants)

    def __contains__(cls, item):
        return item in cls._constants

    def __repr__(cls):
        return f"<ConstGroup {cls.__name__}: {cls._constants!r}>"

class ConstGroup(metaclass=MetaConst):
    """Base class for constant groups (dict + namespace)."""
    pass

Константи за предметними областями

Ось кілька уривків із файлів констант, якими я зараз користуюся:

from db4e.Modules.ConstGroup import ConstGroup

class DField(ConstGroup):
    COLORTERM_ENVIRON : str = "COLORTERM"
    COMPONENT : str = "component"
    COMPONENTS : str = "components"
    CONFIG_FILE : str = "config_file"
    DATA : str = "data"
    DATA_DIR : str = "data_dir"

from db4e.Modules.ConstGroup import ConstGroup
from db4e.Constants.DField import DField

class DDir(ConstGroup):
    API : str = "api_dir"
    BIN : str = "bin_dir"
    BLOCKCHAIN : str = "blockchain_dir"
    DATA : str = DField.DATA_DIR
    DB4E : str = "db4e_dir"
    DEV : str = "dev_dir"    ...

Проблеми з великою кількістю констант

Дублікати

Складно уникати повторів, коли в тебе лише три кошики: поля, мітки та типові значення. Я впорядкував усе за абеткою, але дублікати все одно з’являлися, коли забував про вже визначену константу: наприклад, ver_p2pool і p2pool_ver.

Усе ще негарно

Мій код був засипаний константами. Вони були СКРІЗЬ. А оскільки я запровадив суфікси _FIELD, _LABEL і _DEFAULT, назви вийшли довжелезними. LOCAL_SOFTWARE_SYSTEM_FIELD звучить громіздко, як і MAX_BACKUPS_DEFAULT. Чогось бракувало.

Кілька файлів

Я спробував упорядкувати константи за предметними областями, але спочатку стало тільки гірше. Файли Jobs_Fields.py, Jobs_Defaults.py та Jobs_Labels.py лише збільшили ймовірність дублювання.

Переваги

Я відразу почав отримувати користь від констант.

Автодоповнення

Коли ви використовуєте згруповані константи, VS Code пропонує автодоповнення під час набору. Це справді відчутна перевага: доводиться набагато менше друкувати (клавіша Tab — мій друг!), а ймовірність помилки знову ж таки зменшується (дивіться вище).

Гарніший код

Із константами код у редакторі просто краще виглядає.

Змістовність

Мій код став не тільки гарнішим, а й зрозумілішим. Назви DStatus.ERROR, DDef.MONEROD_VER, DDir.RUN передають зміст.

Перехресні посилання та псевдоніми

Нове рішення також підтримує посилання між групами. Можливо, ви помітили, що DDir.DATA є псевдонімом DField.DATA_DIR. Це не лише дає альтернативну назву, а й допомагає чіткіше висловити задум у коді. Наприклад:

form_data = {
    DField.NAME: DLabel.UPDATE_OPERATION,
    DField.TO_MODULE: DModule.DEPLOYMENT_MGR,
    DField.TO_METHOD: DMethod.POST_JOB,
    DField.OP: DJob.UPDATE,
    DField.ELEMENT_TYPE: DElem.MONEROD_REMOTE,
    DField.ELEMENT: self.monerod,
}

У мене є константа DJob.OP, але це псевдонім: OP : str = DField.OP. Використовувати DJob.OP у словнику мені здавалося неправильним.

Висновок

• Групуйте константи. Не повторюйте моїх помилок: робіть це від самого початку!!!
• Не відкладайте: визначте стратегію роботи з константами на початку проєкту.
• Назви важливі: рано запровадьте єдиний стандарт і дотримуйтеся його.
• Групуйте розумно: групи за предметними областями масштабуються краще, ніж плоскі списки.
• Псевдоніми додають ясності: та сама константа інколи має різний зміст у різних контекстах.
• Рефакторинг окупається: навіть якщо він болісний, інвестиція в структуру робить подальше програмування швидшим і зменшує кількість помилок.

• 2026 19
• 2025 16
• 2024 2