Всем привет.
Очень много букв про очень маленькую проблему ;)
В процессе обсуждения с коллегами одной проблемы у меня случился когнитивный диссонанс.
Короче. У нас есть проект. Проект - это дофига чужого кода, к которому мы пристраиваем немножко своего кода.
Когда мы добавляем свой код, мы обкладываем его:
#if BUILDFLAG (ENABLE_OUR_KILLER_FEATURE_X)
Ну и при необходимости включить этот кусок кода в самый главный хидер добавляется:
#define ENABLE_OUR_KILLER_FEATURE_X 1
Однако, иногда надо *отключать* уже имеющиеся чужие фичи.
Я предположил, что лучше завести флаг DISABLE_THEIRS_CODE.
И обрамлять чужой код в #if !BUILDFLAG(DISABLE_THEIRS_CODE).
В результате "из коробки" чужой код работает, но если записать:
#define DISABLE_THEIRS_CODE 1
то чужой код отключится.
Дальше случилось весёлое. Коллеги встали на дыбы и сказали, что для *единообразия* лучше все флаги именовать как ENABLE_X.
Но для тех (чужих) фичей, которые надо отключить, просто надо прописать:
#define ENABLE_X 0
Результат - у меня когнитивный диссонанс и понимание, что они предлагают фигню, и так делать не надо.
Проблема в том, что кроме интуиции я ничем свою мысль аргументировать не могу. Ну, разве что "есть две задачи - включить и выключить, и задачи разные".
Есть идеи, чем плох вариант использовать для *отключения* фичей флаг с именем ENABLE?
Adamos, если ориентироваться на enable - свой, disable - чужой, то на восклицательный знак смотреть не придётся. Хотя опечатки, видимо, периодически будут вылезать.
Adamos, Нет конечно. Просто сейчас мне придётся использовать другую, тоже недокументированную логику: в одном случае читать enable как enable, а в другом, по сути, читать disable. И таки тоже каждый раз выисивать отрицание.
Весело у вас )
Флаг DISABLE, буде он принят, будет явно указывать то, что он обрамляет легаси-код. Придёт новый программист в команду, прочтёт вот это моё предыдущее предложение, и будет не заглядывая в историю коммитов понимать, что про заенабленые фичи можно спрашивать у коллег, а задизабленые придётся разгребать самому (
В таких случаях надо взвесить все плюсы и минусы.
У твоего варианта какие преимущества? Я не вижу, а из недостатков, что можно запутаться в включением/отключением фич.
А если серьёзно, преимущество в логичности.
Можно говорить, что белое - это белое. Это просто, понятно и логично.
Но в данном случае коллеги предлагают не говорить "белое", а всегда говорить "не чёрное". Потому что так есть только один цвет и так типа проще. О том, что в результате в голове надо делать "лишнее преобразование" они не говорят.
devalone, "интуиция - не аргумент" - именно, поэтому и зашёл сюда спросить.
Про красное... Ну, вроде для enable/disable есть только два состояния. Поэтому моя аналогия кажется уместной :)
Поскольку в любом случае придется лезть в чужой код и обрамлять там что-то, то единообразный подход уменьшит общую сложность восприятия кода.
С психологической точки зрения проблема в том, что вы не хотите брать ответственность за "чужой" код. Как только вы позволите себе взять ответственность за т.н. "чужой" код, потому что он сейчас вовсе не чужой, он ваш т.к. он под вашей опекой, вы взялись за его модификацию, ваше подсознание не будет противится и в результате у вас будет меньше склонностей к внедрению в код лишних сущностей, и в целом работа пойдет быстрее. ( Если переформулировать ваше предложение: вы предлагали вынести на функциональный уровень управления фичами разделение кода в зависимости от просихождения кода. )
Ходят слухи, что с психологической точки зрения частица "не" - это плохо.
Потому что вынуждает мозг сначала представить просто действие и как оно происходит, и только потом добавляет к нему частицу "не". А это лишнее действие.
Вова, верно, но с другой стороны имя флага лишь вершина айсберга, то как флаг называется контролирует проверка/действие, которое он всего лишь представляет как итог.
Если важнее контроль над отключитением кода по признаку авторства, а модификации и этого кода вообще не в приоритете, то ваша позиция более адекватна, чем позиция ваших коллег.
