DEFINE'Ы ПРОЕКТА

В большинстве случаев, делай как удобно и норм.
Но со временем у меня сформировалось 3 подхода к добавление и использованию define’ов в проекте:

1️⃣Восходящий — define’ы и их кол-во определяется фичами, которые используются в проекте. Как бы идем снизу, от фичей.
Начинаются с ENABLE или DISABLE и отключают какой-то функционал, например:
DISABLE_CHEATS, DISABLE_LOGS, ENABLE_SERVER_CONFIGS и т.д.

2️⃣Нисходящий — define’ы и их кол-во определяется потребностями проекта.
Начинаются с имени компании SILVERFOX, ROGAIKOPbITA и отключают/включают целую группу функций, которые должны быть доступны на том или ином окружение.

3️⃣Комбинированный — когда включение одного define’а, включает/отключает несколько фичей. Требует конфигурации глобальных предиктив (те что действуют на весь проект).
К сожалению поддерживается только для проектов, где *.csproj файлы задаются пользователем. В unity эти файлы генерирует только IDE, самому unity они не нужны, т.к. файлы ищутся по всему проекту и отдаются на сборку через csc.exe.

Например вот так в своей студии я организовывал define’ы:
🔹SILVERFOX_RC — отключены читы, отключен fake iap магазин, отключены валидации данных, отключены все логи ниже warning, включена консоль с логами
🔹SILVERFOX_PROD — отключены все фичи отладки и разработки
🔹В случае если ни одна из предиктив не указана, проект собирается со всеми включенными отладками, читами, логами. В общем работает по максимуму на разработчика и поиск проблемы

Плюсы:
🔸Кол-во define’ов полностью синхронизировано с кол-вом веток и их назначением
Про структуру веток, я уже писал тут
🔸Есть четкое понимание когда какой define нужно использовать
🔸Нет проблемы с двойным отрицанием по типу !DISABLE_CHEATS

Минусы:
Как по мне их нет, но если вы нашли, 👨‍💻 в комментарии

На последок не очевидный момент, который заставляет фрустрировать:
♦️Предиктива DEBUG указывает на то, в каком режиме был скомпилирован ваш проект. По умолчанию все c# проекты идут с двумя конфигурациями: DEBUG и RELEASE.
Вот только в unity весь код компилируется только в DEBUG режиме и никак не связан с Development build’ом. Для этого есть отдельный define DEVELOPMENT_BUILD . Это значит, что код под DEBUG всегда будет попадать в финальную сборку.

UPD: про DEBUG я оказался не прав, спасибо @realwar_fx за замечание в комментариях.
Заблуждение сформировалось из-за некачественных проверок мной, а так же из-за отсутствующей документации от unity насчет этого момента. Мое упущение, извиняюсь

Что касается DEBUG:
— Всегда работает в редакторе не зависимо от DEVELOPMENT_BUILD.
Сам DEVELOPMENT_BUILD всегда отключен в редакторе.
— DEBUG включается в билд, только если включен Development Build в настройках
— Debug, Release, Master конфигурации c++ на предиктиву DEBUG никак не влияют
— Release дефайна нет ни в одном из случаев, даже при переключении редактора из debug в release режимы


#проект_с_нуля@UniArchitect