Protobuf и никаких строк нигде

YAML. Меньше всего писать приходится.

JSON во все поля. Но иногда приходится кушать что дают.

.ini

Если выбирать именно из этих сортов говна, то JSON. А так, CSS-подобный велосипед.

УБИВАТ. Уж лучше XML, чем эта параша.

яркий пример logging.config.fileConfig в python:

[loggers]
keys=root,simpleExample

[handlers]
keys=consoleHandler

[formatters]
keys=simpleFormatter

[logger_root]
level=DEBUG
handlers=consoleHandler

[logger_simpleExample]
level=DEBUG
handlers=consoleHandler
qualname=simpleExample
propagate=0

[handler_consoleHandler]
class=StreamHandler
level=DEBUG
formatter=simpleFormatter
args=(sys.stdout,)

[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
datefmt=

JSON для лохов называется.

Не лучше, .ini можно читать.

А почему бы ни все сразу заюзать? Какой язык?

И пусть на той стороне юзают любой другой формат, а ты будешь прилагать тот, который тебе больше нравиться.

Для Go вот такая дура есть: https://github.com/spf13/viper

XML уже лет 10 как в гробу и закопан. Если предполагается редактирование человеком, то YAML, иначе — JSON.

Все варианты гогно. Просто текст или какой-нибудь свой простенький бинарный формат ini подобные или другие свои альтернативи.

s-exp

json, как компромис между читаемостью, поддержкой и машинной обработкой.

Вопрос: Зачем его вообще читать?

По хорошему gui морду из которой можно редактировать XML (или json) данные даже писать не надо - она генерируется.

Если писать руками, то выбора нет - YAML.

TOML же моден и молодежен. А в бусте есть такой зверь как INFO.

выбора нет, всё тлен

Если писать руками, то выбора нет - YAML

а схему тоже руками будешь писать? для xml (который закопан смузи аналитиками) это не проблема.

type:      map
mapping:
 "company":
    type:      str
    required:  yes
 "email":
    type:      str
 "employees":
    type:      seq
    sequence:
      - type:    map
      mapping:
         "code":
            type:      int
            required:  yes
         "name":
            type:      str
            required:  yes
         "email":
            type:      str

Если нужно редактировать сам конфиг - то только ini, иначе json.

JSON отметается сразу — в нём нет комментариев, а это очень важно для конфига.

XML — не, спасибо, не надо.

YAML — при всей своей кажущейся простоте очень сложен для написания, особенно при наличии вложенных структур.

Есть ещё 2 кандидата: TOML (ini-like) и HCL (superset json с комментариями и прочими плюшками)

TL;DR: все они ужасны, нормального нет.

JSON отметается сразу — в нём нет комментариев, а это очень важно для конфига.

Крокфорд возмущен!

I know that the lack of comments makes some people sad, but it shouldn't.

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

Ага, и ты используешь jsmin, не лохмать бабушку. У тебя или тривиальщина в конфигах, для мелкоподелия, или ад и израиль в котором не разобраться.

Что такое структурированный?

xml сразу в топку.

json и yaml оба читабельны. Если человеку нужно только читать, то без разницы. Если и писать, то yaml лучше. В json даже коментариев нет.

Ага, и ты используешь jsmin, не лохмать бабушку.

Не драматизируй. Если уж так нужно описание на каждый чихкаждое поле, то юзай доп. поля для описаний/хак-методы/etc. Али пару лишних байтов пожалел? Ну и всегда есть json-scheme/любой лишний парсер/etc для особо поехавших. Я лично не жалею байтики, поэтому использую просто доп. поля.
Ну и для совсем мазахистовэкстремалов - конфигурируйте сразу уж скриптами, че уж.

А зачем мне схема?

Если уж так нужно описание на каждый чих

Драматизируешь здесь ты.

Ну и всегда есть json-scheme

И как она поможет прояснить семантику конфига?

любой лишний парсер

Зачем? Когда можно просто не писать конфиги в json.

конфигурируйте сразу уж скриптами, че уж.

Для питонячих проектов так и делаю.

Никакой. О XML можно даже не заикаться, ублюдство не годящееся вообще никуда, JSON убог ненужными кавычками и отсутствием комментариев, YAML слишком навороченный.

Самое удобное для сильно структурированного конфига - как у nginx или irssi либо key-value, но намного лучше когда структурированный конфиг не требуется - тогда что-то ini-подобное.

но намного лучше когда структурированный конфиг не требуется

Это фантастика, сынок. Рано или поздно требуется и чтобы не бросать родной ini такое начинается.

Сказки, сотни приложений постарше тебя живут с key=value конфигами. Кроме того, структурированный nginx/irssi-подобный формат делается из key=value сохраняя прямую совместимость тривиальным образом.

если ты решишь использовать протокол, который передаёт в xml\json много данных, ты без проверки схемы эти данные читать будешь?
обмажешься эксепшенами? для перечисленных «языков» товарищи из altova сделали нормальную экосистему.
а конфиги? как это прочитать и быть уверенным что порт не равен нулю или хост - это ipv4 без схемы?

{
  "server": {
    "host": "192.168.10.178",
    "port": 546
  },
  "datastore": {
    "web-proxy": {
      "host": "127.0.0.1",
      "port": 9000
    },
    "default": {
      "host": "127.0.0.1",
      "port": 9000,
      "allow": false
    }
  }
}

Сказки, сотни приложений постарше тебя живут с key=value конфигами. Кроме того, структурированный nginx/irssi-подобный формат делается из key=value сохраняя прямую совместимость тривиальным образом.

Сотни тривиальных приложений? Согласен.

если ты решишь использовать протокол, который передаёт в xml\json много данных, ты без проверки схемы эти данные читать будешь?

А кто ж мне запретит?

Hocon

как это прочитать и быть уверенным что порт не равен нулю или хост - это ipv4 без схемы?

Конкретно человеку не надо быть уверенным. А программа может и проверить. Таким образом можно сделать конфигурацию на чем угодно и она не будет зависеть от схемы. И да, это не так уж и сложно.

s-exp

Що, опять?!

Идеологически рулит произвольный как в Salt Stack.

Если требуется ручная работа, то YAML, если только машинная — то JSON.

XML — сон разума, хотя и популярный.

Squid например очень тривиальное приложение, да-да-да. А там XML-ем или JSON-ом и не пахло.

Squid например очень тривиальное приложение, да-да-да. А там XML-ем или JSON-ом и не пахло.

ini и даже key-value там тоже не пахнет.

s-exp

На Луа же.
PS. Что здесь делают пункты 2 и 3, если у нас не обмен машина-машина и зачем кому-то выше понадобилась схема для чтения своего же собственного конфига не понятно. 1 не встречал ни разу, глубокого залегания похоже.

конфиг nginx самый лучший на свете

YAML на порядке удобнее и читабельнее JSON.

Для небольших конфигов использую обычный key=value или ini.

Идеальная программа сама себя настраивает, ей конфиги не нужны )

при всей своей кажущейся простоте очень сложен для написания, особенно при наличии вложенных структур.

Это как? Не запомнить что `:` для хешей а `-` для массивов :) ?

Самое рисковое в ямле - кавычки пропускать, если не знаешь особенностей. Остальное терпимо вроде.

TOML (ini-like)

TOML - это полный звиздец, взлетевший исключительно благодаря личности автора. Глядя на YAML и общаясь с его авторами я вижу, что он overengineered т.к. в него пытались заложить слишком много интересных идей. Глядя на TOML - я вижу что автор вообще ни хера не в курсе синтаксисов и слепил наболевшее по наитию.

Френд, для валидации есть json-schema. Не вали в кучу разные сущности. XML это конечно круто, и иногда даже нужно, но для многих типовых задач - абсолютно избыточно и не практично.

Использовал все 3. Если человеку надо читать/модифицировать, xml. json совсем уж не для конфигов. В yaml вникать надо, поскольку не особо он распространён, но если в конфиге есть подстановочные параметры, то он удобен, емнип.

Френд, для валидации есть json-schema

Слышал звон? Там даже 10ой части нет от xsd. Такая же наколенная поделка как и все от фронтменов.