this post was submitted on 12 Nov 2023
761 points (96.7% liked)

Programmer Humor

18970 readers
521 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 1 points 9 months ago (1 children)

Honestly that probably goes for any interpreted programming language that supports imports.

Many Javascript frameworks just put their configuration into -.config.js files in the project root. Which is a pretty elegant solution that does not require custom parsing. Just import the config and go nuts.

Compiled (and by extension bundled) software obviously requires a different approach, but at that point you should probably consider storing your config in some kind of database.

Maybe there just isn't a right answer to the config conundrum if all the general solutions are janky in some way.

[โ€“] [email protected] 1 points 9 months ago

Well, there's a few things I personally think are a must for a config format:

  1. It must be human readable and editable, in some way. - in many cases, you may want to go and change something in the config while the application proper isn't running. That rules out stuff like pickle or binary formats. Although I suppose sqlite and it's ilk still fulfill it, in a roundabout way.
  2. It should be unambiguous, with one way to do something right. - this one's a doozie. JSON fulfills it since it's unambiguous about it's types, but many interpreted language configs will have options. And then YAML will have "no" turn into "false".
  3. It should probably have comments. - handily failed by standard JSON implementations. Although to be fair a lot of parsers I've used understand comments. Or you can make a comment stripper real easily.
  4. It should have obvious structure. - I've dealt with CSV configs before, I do not want to ever again.