Programming

28249 readers

303 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

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 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

Discussion: Programming conventions for On/Off functions. Singular or separate? (lemmy.world)

submitted 6 days ago* (last edited 6 days ago) by Mexigore@lemmy.world to c/programming@programming.dev

12 comments fedilink hide all child comments

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);
}

you are viewing a single comment's thread
view the rest of the comments

[–] one_old_coder@piefed.social 13 points 6 days ago* (last edited 6 days ago) (2 children)

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)

[–] TiredDinoByte@lemmy.today 1 points 3 days ago* (last edited 3 days ago)

I disagree, that it is mostly preference. I agree that it has been implemented both ways, but once you get into the scalability question, it becomes clear that passing in an argument cuts down on the logical branching. If you have both an enable and a disable function as your pattern, then for components you need to reason about state for during runtime will need an if/else which can get out of hand quickly when you are driving multiple component states.

[–] SpaceNoodle@lemmy.world 5 points 6 days ago

Building on this: naming a function something like "LEDSetEnable" can make it clear what a Boolean argument would mean without using enums.