I would use an enum. Booleans are bad, because they don’t tell you what true means. 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 1 is 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…

The main problem here is naming, because I don’t think there’s an English word that means “set whether this thing is enabled or disabled.” Maybe there is, and if you can come up with one, I think a combined function would be OK. If it’s clear that “not enabled” is the same as “disabled” then setEnabled is an OK function name.

Another consideration is whether you typically have a boolean already that indicates the desired state (e.g. from a config file), or whether you work out whether to enable or disable this thing based on more complicated logic. If it’s the former, and you have to do this in several places, maybe the convenience of being able to just do setEnabled(flag) beats having to do if (flag) { enable(); } else { disable(); }.

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.

From what I saw, it’s mostly a preference. Some libraries do everything: SetState, Enable, Disable , TurnOn , TurnOff (like in VTK), OR others only have one SetState. I think it’s fun to have some choice, but too many choices can be a burden later on when you decide to change the API. Fixing too many functions is annoying even with regular expressions.

Nitpicking : I would use an enum class in C++. It’s not ideal in C but you could do the same with a regular enum in C, like LedSetState(LED_PIN, LedEnabled);. A boolean is not technically a “state.” I.e. state==true means nothing to me. Is it state enabled, stated pushed, state triggered, state opened, stated validated? It depends on the context. And what happens when you need to combine the states later on, like LedEnabled | LedTriggered? A bool may miss some information. To make sure that you use the good values for the enum, there may be a compilation warning flag to check that.

And you could add “defines” for enable and disable, like: #define LEDEnable(LED_PIN) LEDState(LED_PIN, LedEnabled) or something.

(remember that I’m nitpicking, the only embedded stuff that I ever did was in C++20)

What’s common among other C++ programs in a similar ecosystem? Mimic that.

For instance, among OTP applications in Erlang, it is common for an application to publish a :start/0 and :stop/0 function, alongside :load/0 which neither stops nor starts, and sometimes :connect/1 and :disconnect/1 functions.

I wouldn’t use SystemState for a boolean. Better to have Enable() or Disable().

The consideration is about what the consumer of that code knows about it. If it knows less about the inner workings and state, it has lower coupling. You can more easily change 1 without changing all the callers of it. Ideally code, especially in object oriented programming should have high cohesion (each class has one purpose and one reason for change) and low coupling.

Most stuff depends but those concepts can guide you. Learning SOLID principles helps to write better code.

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

fn enable(&self, enabled: bool) {
    self.enabled = enabled;
}

“State” can mean too many things. Just have one function “enable”. And if your language allows default parameter values, set to true by default

It is just preference and consistency with other APIs imo. However, personally when I see LEDEnable or LEDDisable I feel like a teeny tiny bit more will happen inside the function meanwhile LEDState is like only changing a variable or something. Also I would like LED_Set(bool enabled) or if there are more LED_SetEnabled(bool b) better.