I usually use Json5. It's JSON, but with all the weird quirks fixed (comments added, you can use hex numbers, you can have trailing commas etc.)
this post was submitted on 15 Aug 2023
37 points (100.0% liked)
Experienced Devs
3981 readers
1 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 2 years ago
MODERATORS
JSON by a mile. I hate the YAML plague, it’s some of the most unintuitive syntax I’ve seen and yet it’s everywhere in DevOps/SysOps.
The only thing that really annoys me about JSON is that it doesn't allow comments.
JSON5, bay-beee
GitHub Actions and Azure DevOps had me hating on YAML pretty quickly
YAML works better with git than JSON, but so much config work is copy and pasting and YAML is horrible at that.
Having something where changing one line doesn't turn into changing three lines, but you could also copy it off a website would be great.
The one with a validator provided to the user.
It depends what you need your configuration file to be:
Need a well defined easy to understand concrete configuration file?
- Use
.toml. It was made to be both human and computer friendly while taking special attention to avoid the pitfalls commonly found in other configuration files by explicitly stating expected types around commonly confused areas.
Need a simple to implement configuration file?
- Use
.json. It's famous for being so simple it's ~~creator~~ "discoverer" could define it on a business card.
Need an abstract configuration file for more complicated setups?
- Use
.ncl. Nickle allows you to define functions so that you can generate/compute the correct configuration by changing a few variables/flags.
A lot of good answers but I would add one note:
- use a format that supports comments, and JSON is not one of those...
I believe the JSON deserializer .NET ships with has options to allow C#-style comments in JSON files.
json with comments can be parsed by a yaml parser. It's how I write yaml, in fact (yaml is a superset of json. any valid json is valid yaml, but it also supports comments)
JSON5 is a superset of JSON that supports comments.
.ini
ducks
Give the windows registry a shot.
Yaml for me, I really like it. And the fact that every valid JSON is also a valid YAML is nice.
YAML here as well.
Configuration many levels deep gets so much harder for me to read and write in JSON with all [], {} and ""
Also the lack of comments... And YAML still is more used in software I'm using than JSON5, so I'd rather skip yet another format/library to keep track of.
It's like yaml but simple, consistent, untyped, and you never need to escape any characters, ever.
Types and validation aren't going to be great unless they're in the actual code anyway.
No reason to go beyond simple key-value format like dotenv or just env variables. If you need more structure then maybe you are confusing configuration with state and this is not really the same thing.
It really depends. I usually prefer json. It's easily understandable from humans and from machines, it doesn't depends on indentation and above everything else I like it very much 🤣
.xml
XML would be great if it wasn't for the extended XML universe of namespaces and imports.
Bruh. I want to use this for my dotfiles. Thanks for sharing it!
You might want to checkout NixOS (or home-manager if you don't want a cold deep dive into a rabbit-hole).
You're probably right I have checked it out, but so far home-manager was a bit of a cold shower to me. I had a ton of trouble wrapping my head around which parts of what config should be responsible for what - and lots of the documentation seems to either be out of date or relying on thing that are still in the 'testing' stage?
I'm interested, but so far just found it frustrating.
Hmm yeah it probably helps to be able to program functionally (it's basically lambda calculus with lazy sets and a little bit of syntax sugar). NixOS has a little bit of a steeper learning curve. When understanding Nix itself and having a little bit dived into the the nixpkgs repo you'll quickly get a grip for it (and understand some of the IMHO quirky design decisions).
But then I feel it's only going to get better, as the system can be perfectly configured to your liking and it stays like that across different machines etc. I think the initial investment has paid off for me so far. It's really hackable and you can quickly try ideas without having to fear to break your system. Also something like nix flakes for good reproducible dependency management across different OS is really nice (at least if not much if any GUI is involved, then the different worlds (impure vs pure) sometimes clash together).
Depends on what you mean exactly with "file format".
If declarative functional programming falls under that, I think something like Nickel, the already mentioned Dhall or Nix. Though Nix more so for packaging and some kind of system management (NixOS?), it's not easily embeddable into a runtime (your app?). Nickel or Dhall is better for that, as they are built from ground up with that in mind, Nickel is maybe the successor of Nix as it is inspired by Dhall and Nix (one goal is to use it Nickel as frontend).
The reason why I recommend a simple declarative language, is that that they are much better composable as it lets the user hide boilerplate via functions. I almost always feel limited by static configuration formats like yaml, json etc..
Need it to be user editable in a text editor? YAML. Otherwise, JSON.
Whatever. Comments are helpful, which makes pure JSON a poor choice. JSON5 or JSON-C are better, but linting and static analysis are important to every form of code, so make sure that what you use for that will understand your syntax.
My current preference is generally TOML, but I've started dabbling with custom HCL2 DSLs. (I write a lot of Go and Terraform.)