Философия, или когда буквы были зелёными

[Alex_ME]

Или JSON. YAML чувствителен к лишним пробелам.

[Alex_ME]

Да, по поводу мусора соглашусь с Вами.

Приведенный выше YAML и JSON в сравнении

Картинка

[technont64]

или TOML :)

[atd]

я не настоящий программист, но на ваш ц++ смотреть без боли просто нельзя (

[opaopa]

Жаль, что в статье не упомянут критически важный в больших системах плюс текстовых конфигов: легко строится протоколирование и анализ истории и причин изменений.

diff же для GUI… так и не придуман. То, что я видел в 1C… это забавно.

[Amomum]

Сделать хороший текстовый конфиг — тоже не так-то просто, на самом деле.
Помнится, пришлось мне пользоваться одной САПР, которая настройки в файле хранила…

• Настроек было пару тысяч, изначально в файле присутствовала пара сотен.
• Настройки назывались типа «allow_harn_mfg_assy_retrieval » или «style_grid_spacing». Разумеется, среди них были ну очень похожие по названию, но совсем разные по действию.
• То, что в файле уже было, не было отсортировано по алфавиту или еще как-то сгруппировано, просто все подряд навалено.
• Некоторые опции конфликтовали друг с другом.
• Разумеется, существовали огромные талмуды, где перечислялись все возможные опции, только надо было тщательно смотреть на соответствие версии талмуда и версии САПРа, потому что старые опции переставали работать, зато появлялись новые.

Причем я так и вижу, что давным-давно этих опций было штук 10 и кто-то подумал — «Да лааадно, и так вроде все понятно».

Так и не удалось мне рамку по ГОСТу сделать.

[zabbius]

Имхо чем городить очередной кастомный синтаксис, проще взять что-нибудь стандартное (yaml, json, ini наконец).
А для тех, кто ну очень хочет тыкать мышкой, можно добавить GUI редактор конфига.

[MacIn]

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