Комментарии 30
А ещё можно просто переключиться на jsonnet :)
С соответствующими плагинами и подсветкой синтаксиса он нисколько не отстаёт от yaml по читаемости и удобству редактирования, но также привносит новые возможности и позволяет полностью избавится от повторяемости однотипных структур.
{
[x.login]: {
job: 'Developer',
name: x.name,
skills: x.skills,
}
for x in [
{
login: 'martin',
name: "Martin D'vloper",
skills: ['python', 'perl', 'pascal'],
},
{
login: 'tabitha',
name: 'Tabitha Bitumen',
skills: ['lisp', 'fortran', 'erlang'],
},
]
}
Я получил адский wtf в yaml на таком примере:
continious_queries:
- name: cq1
on: db1
- name: cq2
on: db1Догадайтесь, во что превратилось 'on:db1'? Правильно, в true:"db1", потому что какой-то умник в yaml решил, что on, true, yes — всё это bool.
Мне ямл нравится за работу с многострочными текстами. Выбрал его для своего проекта как формат бизнесправил. Удобный.
Или переходите на Tree. Его парсер можно написать всего за пол часа на любом языке. В нём не надо решать проблему "табы или пробелы" — она уже решена.
Пример:
martin
name \Martin D'vloper
job \Developer
skill \python
skill \perl
skill \pascal
about \
\Клёвый чел.
\Но помер, прочитав спецификацию YAML до конца.
tabitha
name \Tabitha Bitumen
job \Developer
skill \lisp
skill \fortran
skill \erlang
about \
\Написал свой YAML парсер.
\С тех пор умеет ходить на руках.
\Пятью разными способами.Закопайте это, оно уродливо.
Более чем в 2 раза более сложная грамматика, чем у XML, — это конечно верх красоты.
Уродливость определяется не размером парсера, а возможностями решить проблему. Вот в этом новоизобретённом формате, запишите мне вот этот yaml, пожалуйста:
- " ": " "
- "\": |
skill \lisp
skill \fortran
skill \erlang
# not a comment
# this is a commentЯмл может это с минимальной болью.
Сперва расшифруйте, что вы написали, и объясните, что за проблему вы решали таким непонятным, уродливым и, что самое смешное, в очередной раз невалидным кодом.
Список, в котором первый элемент — словарь у которого ключ пробел, а значение два пробела, второй элемент — словарь, в котором ключ '\', а значение — буквальный текст
skill \lisp
skill \fortran
skill \erlang
# not a comment(прям как есть, с переводами строк)
А дальше там комментарий.
У меня к вам 2 вопроса:
- Вы хоть раз смогли написать валидный YAML с первого раза?
- В какой задаче может потребоваться объявлять в словаре пробел и бэкслеш в качестве ключей словаря?
Очень хочу ответить про ямл. У меня правила на нем, 1000строк. Пишу постоянно и легко. Sublime умеет подсвечивать скобки и пр выделители, ставит вертикальные полосы на отступах и автодополнение пашет с подсветкой синтаксиса. В общем ямл в таких условиях хорош, особенно хорошо когда многострочники писать надо.
У меня правила на нем, 1000строк.
Покажете пример?
В общем ямл в таких условиях хорош
Тут скорее Sublime хорош. Для Tree тоже есть к нему плагин.
особенно хорошо когда многострочники писать надо
Если речь про многострочный текст, то можете обратить внимание на пример tree-кода выше.
Странным выглядит предложение конвертить yaml в json для чтения, а не наоборот. Ведь миссия yaml как раз в повышении человеко-читаемости. И на мой взгляд он хорошо справляется с этим, попробуйте прочитать или написать с нуля без IDE — xml, json и yaml.
Достаточно их считать. Мне хватает. Обычный стек в уме.
И вот вам надо добавить элемент на том же уровне, что и три экрана вверх, а пробелы не показаны, и вертикальной разметки нет :)
По последнему совету лучше на Tree перейти — он и проще, и линтер ему не нужен, и пробелы запрещены.
https://m.habr.com/ru/post/503240/
10 шагов к YAML-дзену