Say I have a system that I want to enable or disable, what do you think is best: to write two separate functions EnableSystem() and DisableSystem() OR have a singular function with the parameter to indicate the desired state, SystemState(bool state)?
I was wondering if there is a standard for this or a preference?
I would argue that having two separate functions is better since different things might happen under those functions but what if it is the situation where it really is just as simple as a 1 or a 0. Example if we have an LED we want to turn on an off it would just be passing the value of the parameter state.
Situation one:
void LEDEnable() {
GPIOPinSet(LED_PIN, true);
}
void LEDDisable() {
GPIOPinSet(LED_PIN, false);
}
Situation two:
void LEDState(bool state) {
GPIOPinSet(LED_PIN, state);
}Type systems are obligation propagation mechanisms. What obligations would you like to ensure propagate?
If you someday decide to introduce a third state, would you want the compiler to force you to reconsider each call site? If so, you need to use a parameter that you can later widen.
If you specifically don’t want to have to reconsider each call site if a third state becomes available, then use the separate functions.
Ideally, any function should be idempotent and maximally expressive. If I’m reading code and I hit setState(bool) then I have to go find where the bool is set. toggle() is worse. Foo.enable() is perfect because when I hit that code I only need ordinary domain knowledge to understand. Similarly, prefer isEnabled() to getState(). IsDisabled() is a little iffy, but I like it because it helps streaming functions to read a bit easier to have both, but it depends on the language you’re using. Java is notorious for its verbosity, but I like it.
Correct answer - depends.
Option 1 if enabling led is action itself, not side effect. This would justify having enable/disable specific side effects in those functions. This is unlikely for given example. Enabling/disabling led likely side effect itself. You don’t want to put side effects into side effects.
Option 2 if it’s a side effect of bigger process. Option 2 makes harder to add side effects which will drive (but not guarantee) better separation of concerns.
Though, I’d go with option 1 anyway since I trust my self to not nest side effects even when code doesn’t hint me
I would use an enum. Booleans are bad, because they don’t tell you what
truemeans. And specifically named functions are bad, because you cannot pass them through the codebase as data (without resorting to entirely functional patterns).I mean, your examples are in C, which has shit enums that are just integers, so at runtime you won’t know either what a
1is without context.
And I believe the compiler doesn’t stop you either from passing a different enum or just an integer into a parameter with that enum as type.
But at least it’ll be written in the code what you hope to get passed, so…
