Which do you prefer? A programming question!
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptionsthe first. Almost without exception always. Even if the logic starts to get complex. It will still be understandable to read. PAinful potentially. but the second is harder to read and the more complex it gets the better in comparison to the first, but the first will always be more readable. IMO. ymmv. and all that quid pro quo that goes with all that.
To err is human to really elephant it up you need a computer
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsTo me, it mainly depends on whether
foois incidental to (option #1), sufficient for (option #2), or necessary for (option #3) the execution ofDoSomething(). Option #3 would be refactoringDoSomething()to includefooso not always an option. So iffoogatekeeps the execution ofDoSomething()in this one spot but not others then it's incidental. IffoogatekeepsDoSomething()in a lot of spots but not all then it's sufficient. Iffooalways gatekeepsDoSomething()then it's necessary. -
Both have a usage. If it's code that is going to be reused somewhere else, version 2. If it's lots of crazy complicated code, version 2. If it's pretty simple and not reused, version 1.
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsI much prefer the first method. Having said that I have been trying to dis the second method and the only things I can say is it looks ugly and is doing more than one thing (both testing if something can be done and doing it.) It has the advantage that the test is explicit that it should be done. And yes, I have well over-thought this... :confused: -showing my working out- Renaming the foo variable to suit what it is being used for:
if (canDoSomething)
{
DoSomething();
}or:
DoSomethingIfPossible(canDoSomething);
...
DoSomethingIfPossible(bool canDoSomething)
{
if (canDoSomething)
{
// do the something.
}
}Or, if renaming the variables is not viable you could try these three convoluted options:
if (CanDoSomething(foo))
{
DoSomething();
}bool CanDoSomething(bool canDoSomething)
{
return canDoSomething;
}or:
DoSomethingIfPossible(CanDoSomething(foo));
...
DoSomethingIfPossible(bool canDoSomething)
{
if (canDoSomething)
{
// do the something.
}
}bool CanDoSomething(bool canDoSomething)
{
return canDoSomething;
}or:
DoSomethingIfPossible(foo);
...
DoSomethingIfPossible(bool foo)
{
if (CanDoSomething(foo))
{
// do the something.
}
}bool CanDoSomething(bool canDoSomething)
{
return canDoSomething;
} -
Both have a usage. If it's code that is going to be reused somewhere else, version 2. If it's lots of crazy complicated code, version 2. If it's pretty simple and not reused, version 1.
Agreed! :)
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
I much prefer the first method. Having said that I have been trying to dis the second method and the only things I can say is it looks ugly and is doing more than one thing (both testing if something can be done and doing it.) It has the advantage that the test is explicit that it should be done. And yes, I have well over-thought this... :confused: -showing my working out- Renaming the foo variable to suit what it is being used for:
if (canDoSomething)
{
DoSomething();
}or:
DoSomethingIfPossible(canDoSomething);
...
DoSomethingIfPossible(bool canDoSomething)
{
if (canDoSomething)
{
// do the something.
}
}Or, if renaming the variables is not viable you could try these three convoluted options:
if (CanDoSomething(foo))
{
DoSomething();
}bool CanDoSomething(bool canDoSomething)
{
return canDoSomething;
}or:
DoSomethingIfPossible(CanDoSomething(foo));
...
DoSomethingIfPossible(bool canDoSomething)
{
if (canDoSomething)
{
// do the something.
}
}bool CanDoSomething(bool canDoSomething)
{
return canDoSomething;
}or:
DoSomethingIfPossible(foo);
...
DoSomethingIfPossible(bool foo)
{
if (CanDoSomething(foo))
{
// do the something.
}
}bool CanDoSomething(bool canDoSomething)
{
return canDoSomething;
}I like the "IfPossible" version as well. I'll have to remember that.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsHow about:
#define DOSOMETHING_IF(A) if((A)) DoSomething()
- No extra calls if condition is false. - No repeated if statements visble
Mircea
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsThere are only three acceptable reasons for creating a function: 1. If there is more than one occurrence of the segment of code. 2. It makes reading the code more logical.
if(itShouldBeDone(foo)) {
doSomething()
}3. to confuse the next poor soul who gets to work on your code.
function itShouldBeDone(foo){
return decideWhatToDo(foo);
}function decideWhatToDo(foo){
let decision= false;
if(typeof foo == "boolean") {
switch(foo){
case true:
decision= foo;
break;
case false:
decision= !foo;
break;
default:
decision= true;
}
}
return false;
}Nothing succeeds like a budgie without teeth.
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsDefinitely the first one. Low level functions should only do things, preferably in a class that can get mocked during testing. High level functions should decide which things are worth doing, and are prime targets to test.
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsI prefer the first as the DoSomething() function is explicit what it does. just like the second it encapsulates all actions to be done, that is what functions are made for. The second MaybeDoSomething(bool foo) function is less explicit. Is the "maybe" related to the bool parameter? Suppose so, but that is an assumption, or? And will it "doSomething" if the parameter is false or when the bool is true? For me the first construct does not have these question and is therefor more clear.
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsIt depends. If The Something is part of the business logic I would encapsulate it, if it is simple flow control I wouldn't. Encapsulating in a different subroutine offers better options for bugfixing, bug reporting, logging, maintenance, refacotring, rewriting, whatever.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsOption 1 unless there is a need for re-use. Going back to my days in machine code when every clock cycle counts then the overhead of the call to a method would leave me no choice but to use option 1.
-
foo ? DoSomething() : ;:-D Simpler is better!The Science of King David's Court | Object Oriented Programming with C++
:rolleyes: This isn't the obfuscated C contest, and there is no prize for using the minimal number of keystrokes.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsDepends on context but esp. in complex scenarios I like the second form because it allows for having clearer understand of the flow while being composable: I could have a bigger methods which calculates certains states and then calls several MayBe-methods... It allows the MayBe-method to be called based on the state which in turn can be easily serialized and deserialized (which is not so easy with an "if"-Statement).
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptionsfrom a debugging point of view the second is a nightmare, you need to step into the maybe to know if it happend or not. I will take the first code any time
-
What if (no pun intended), the "if" actually required more complex logic, including perhaps some nested stuff, like:
if (foo != null)
{
var data = GetSomeData(foo.SomeValue);if (data has some specific value/s)
{
DoSomething();
}
}From an aesthetic point of view, I dislike putting all that into the main method, hence why I've got a couple "Maybe..." methods because the above scenario matches in pseudo-code what I'm actually having to deal with.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsMarc Clifton wrote:
What if (no pun intended), the "if" actually required more complex logic, including perhaps some nested stuff
This is a different question. The original question is very simplistic. If we were discussing a real scenario, I'd ask what is the conditional logic, how many times will it be repeated and in what context(s), how large is the function in which it's called, etc. But for this simplistic scenario, I'd use #1 because it is not efficient -- either in coding and probably execution -- to call a function for no useful reason.
-
if (foo)
{
DoSomething();
}or:
MaybeDoSomething(foo);
...
MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something.
}
}eh?
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptionsthis reminds me of a code review comment I received, for using:
while (true)
{
// About 30 FAILURE comparisons for rating an insurance policy like this;
failure_code = 123;
if (failure_condition1) break;
failure_code = 125;
if (failure_condition2) break;
...failure_code = 0; // Success
break;
}if (failure_code>0)
process_error(failure_code);
else
process_policy;To me, the fake structure of the while loop supported the early exit (once we know we failed) The code was so overly complicated (insurance rules), that I could only prove correctness by literally applying the "rules & regs" line by line! For what it's worth, the Business Analyst could understand, and the programmers complained that the while loop was throwing them off. [Comments were added]