> И да, похоже аноним не понял, в чем "прелесть" конструкции
> else if (l == 20 && strneq(word, "handle-hibernate-key", l))
> what |= INHIBIT_HANDLE_HIBERNATE_KEY;
> else if (l == 17 && strneq(word, "handle-lid-switch", l))
> вместо
> else if(token.HANDLE_HIBERNATE_KEY) …А я могу объяснить в чём прелесть. Чтобы сделать if(token.бла-бла-бла), придётся писать лишних строк пятьсот кода, с объявлением структуры token, и потом эти пятьсот строк кода будут в течение неопределённого времени получать патчи связанные с тем, что кому-то что-то надо было сделать, но оно не делалось нормально, кроме как через патч в библиотечный код. Типа мы изменили немного семантику флага в конфиге, поэтому мы теперь меняем структуру токена, переносим константы из одного enum'а, в другой enum, затем меняем содержимое статических массивов, по которым генерятся хештаблички для быстрого поиска. Затем мы вносим ещё парочку изменений, без которых код не компилируется. А потом мы запускаем аудит всего кода, который пользуется этой структурой, для того, чтобы убедиться, что мы ничего не поломали. На последнем этапе могут помочь тесты, но помочь относительно: мы в результате получим грядку тестов, которые не будут компилироваться, или которые будут фейлится, и нам придётся их переписывать. Груда никому не нужных усилий.
Если эти ненужные усилия всё же последовательно прилагать, то в результате код раздуется до полутора (двух, трёх...) тысяч строк кода. Будет получена какая-то мутная абстракция, которой пользоваться могут только те, кто её создавал. Да и они через год забудут. Значит придётся писать подробную документацию, причём не просто API с описанием точек входа и типов, а целый мануал на тему, как это использовать в тех или иных случаях. А это значит, что количество усилий на изменение семантики флага возрастёт ещё: придётся ещё и документацию на API парсера исправлять каждый раз.
Зачем все эти сложности? От этого код станет короче? От этого он станет понятнее? Понятнее в смысле, "понятнее что код делает", или в смысле "понятнее как код делает, то что он делает"? Код будет проще поддерживать? Это риторические вопросы, потому что ответы на них "незачем, эти сложности в этом месте не нужны", "нет", "нет", "некорректный вопрос: ни в каком смысле понятнее не станет", "нет".
