.yaml, .toml, etc?
pileghoff ( @pileghoff@programming.dev ) 19•11 months agoI 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.)
MNByChoice ( @MNByChoice@midwest.social ) 15•11 months agoThe one with a validator provided to the user.
simonced ( @simonced@lemmy.one ) English13•11 months agoA lot of good answers but I would add one note:
- use a format that supports comments, and JSON is not one of those…
AeroLemming ( @AeroLemming@lemm.ee ) English14•11 months agoOf course it does!
{ comment: "This data is super important and it runs the system or something", data: ["Some", "stuff", "here"] }
noli ( @noli@programming.dev ) 15•11 months agoYou disgust me
simonced ( @simonced@lemmy.one ) English1•11 months agoThis is actually pretty genius, why haven’t ever thought of that?
AeroLemming ( @AeroLemming@lemm.ee ) English1•11 months agoIt’s so easy to use, and you can read the comments from in your program too!
^(in case you weren’t just playing along, please never do comments this way)
simonced ( @simonced@lemmy.one ) English1•11 months agoI liked the idea to be honest. I can just call the entry “description” instead and all is good ^^
AeroLemming ( @AeroLemming@lemm.ee ) English2•11 months agoIdeally, you would use TOML for human-readable configuration and document your JSON API with external documentation instead of sending comments around a bunch. If you need to display the description to the end user though, that would be a valid use case.
sfera ( @sfera@beehaw.org ) 1•9 months agoHow do you comment multiple properties separately?
AeroLemming ( @AeroLemming@lemm.ee ) English2•9 months agoPlease don’t actually do this. Comment stuff in the code and documentation, not the JSON.
sfera ( @sfera@beehaw.org ) 1•9 months agoDon’t worry, I wouldn’t do things like this in JSON. Nevertheless, it can be very useful to have comments along with configuration values, for example to explain the actual values (not their purpose) and why they were chosen. That’s information you can’t add to the code which processes the values.
𝙲𝚑𝚊𝚒𝚛𝚖𝚊𝚗 𝙼𝚎𝚘𝚠 ( @ChairmanMeow@programming.dev ) 2•11 months agoI believe the JSON deserializer .NET ships with has options to allow C#-style comments in JSON files.
vrighter ( @vrighter@discuss.tchncs.de ) 2•11 months agojson 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)
kersplort ( @kersplort@programming.dev ) 1•11 months agoJSON5 is a superset of JSON that supports comments.
- Rikudou_Sage ( @rikudou@lemmings.world ) 12•11 months ago
Yaml for me, I really like it. And the fact that every valid JSON is also a valid YAML is nice.
- argv_minus_one ( @argv_minus_one@beehaw.org ) 4•11 months ago
Please do not use YAML. It’s a syntactic minefield. It also doesn’t allow tab indentation, which is supremely irritating.
- Rikudou_Sage ( @rikudou@lemmings.world ) 3•11 months ago
As I said, I like it the most, so I will use it. I like its syntax (except for yes and no for booleans, but nothing’s perfect). I don’t care much for tabs vs spaces, I use tab in my IDE and whatever it does, it does.
Magnus Åhall ( @magnus@lemmy.ahall.se ) 4•11 months agoYAML 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.
aport ( @aport@programming.dev ) 12•11 months ago.ini
ducks
coloredgrayscale ( @coloredgrayscale@programming.dev ) 2•11 months agoGive the windows registry a shot.
spartanatreyu ( @spartanatreyu@programming.dev ) 12•11 months agoIt 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’screator“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.
- Use
Andy ( @Andy@programming.dev ) 7•11 months agoIt’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.
vrkr ( @vrkr@programming.dev ) 5•11 months agoNo 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.
Edo78 ( @Edo78@feddit.it ) 5•11 months agoIt 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 🤣
bignavy ( @bignavy@programming.dev ) English5•11 months ago.xml
kersplort ( @kersplort@programming.dev ) 4•11 months agoXML would be great if it wasn’t for the extended XML universe of namespaces and imports.
philm ( @philm@programming.dev ) 5•11 months agoDepends 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 Nickel as frontend).
The reason why I recommend a simple declarative language, is that they are IMHO 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…
greysemanticist ( @greysemanticist@lemmy.one ) English1•11 months ago lorefnon ( @lorefnon@programming.dev ) 1•11 months agoTyson is nice - esp. if you are already using TS/JS.
I remember reading that article a while ago that I believe expresses concisely why yaml is rarely (almost never?) a good choice.
I would agree with the TOML recommendation at the end of the article or to switch to an even simpler format for simpler needs, something easy to read, hard to mess up when writing and easy to parse. I’m not sure about that scale, maybe ini files? Suggestions are welcome.