108
Don't require people to change 'source code' to configure your programs
(utcc.utoronto.ca)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 10 Apr 2024
108 points (95.8% liked)
Programming
17671 readers
156 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
This is a really important principle of making APIs that people don't really talk about. There's a fine balance between hardcoded literals and full-gui options menu.
Every piece of data in your program has a different level of configurability, and you need to make that trade-off to decide how hard or easy it should be to change. You could hardcode the data as a literal, or you could hoist it to the top of your source file as a const. You could have a separate static const configuration class, or you could have a runtime configuration file. You could even go for an interactive configuration editor/ options menu. It's all a tradeoff based on offering your users choice but not overburdening them with it, as well as balancing development cost.
I know it's not always that straight forward. But that's why it's so important to pick sane defaults, and be very transparent in the documentation.
I think this principle might fly under some people's radar because it has been a solved problem for decades.
Even Makefiles don't require changes to the file to be configured. They take environment variables as input parameters, an approach that directly and indirectly permeated into high-level build systems. One example is the pervasive use of the
VERBOSEflag.After all these years I only had to tweak build config files by hand when I wanted them to do something that they were not designed to do. All build tools I know don't require it. The ones linked with IDEs already provide GUIs designed with this in mind.