|
I would normally use (1), but if there were many such usages, I might consider (2).
The advantage of (2) is that if it turns out that the conditional must be modified, it only need be done in one place:
Marc Clifton wrote:
MaybeDoSomething(foo);
...
void MaybeDoSomething(bool foo)
{
if (foo)
{
}
}
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
foo ? DoSomething() : ;
Simpler is better!
|
|
|
|
|
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.
|
|
|
|
|
Obfuscated is when you use partial template specialization for the task!
|
|
|
|
|
it wasn't me, i swear!
*hides*
Real programmers use butterflies
|
|
|
|
|
|
Not a fan of the second form. If the condition was something else, sure. But otherwise I say: the shorter a boolean lives, the better. Ideally they don't even become "reified": just an ephemeral condition that is used immediately when created, never stored in a variable. Boolean variables are a plague.
|
|
|
|
|
I prefer the former, why make the call if there's a problem?
The less you need, the more you have.
Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?
JaxCoder.com
|
|
|
|
|
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.
|
|
|
|
|
True there are always exceptions but for the simple example you gave I still prefer the former for the less complicated logic.
The less you need, the more you have.
Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?
JaxCoder.com
|
|
|
|
|
Marc 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 the test is complex and gets used more than once, there's an argument for giving the test its own method. That way the test is isolated, and can be changed later, but it's not hidden away in the MaybeDoSomething method. So you might end up with
if (TestIfWeNeedToDoSomething( ... ))
{
DoSomething();
}
// lots of code follows.
if (TestIfWeNeedToDoSomething( ... )) // again
{
DoSomething();
}
and so on. A little inelegant, though.
|
|
|
|
|
That is a different situation than posed. The overhead of a function call could be justified in this case.
|
|
|
|
|
I'm with all the others: first version is what I'd use.
It's easier to read, more efficient, and potentially means you don't have to carry the "decision variable(s)" through to the called method.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
the 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
|
|
|
|
|
|
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!
|
|
|
|
|
To me, it mainly depends on whether foo is incidental to (option #1), sufficient for (option #2), or necessary for (option #3) the execution of DoSomething() . Option #3 would be refactoring DoSomething() to include foo so not always an option.
So if foo gatekeeps the execution of DoSomething() in this one spot but not others then it's incidental. If foo gatekeeps DoSomething() in a lot of spots but not all then it's sufficient. If foo always gatekeeps DoSomething() then it's necessary.
|
|
|
|
|
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...
-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)
{
}
}
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)
{
}
}
bool CanDoSomething(bool canDoSomething)
{
return canDoSomething;
}
or:
DoSomethingIfPossible(foo);
...
DoSomethingIfPossible(bool foo)
{
if (CanDoSomething(foo))
{
}
}
bool CanDoSomething(bool canDoSomething)
{
return canDoSomething;
}
|
|
|
|
|
I like the "IfPossible" version as well. I'll have to remember that.
|
|
|
|
|
How about:
#define DOSOMETHING_IF(A) if((A)) DoSomething()
- No extra calls if condition is false.
- No repeated if statements visble
Mircea
|
|
|
|
|
There 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.
|
|
|
|
|
Definitely 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.
|
|
|
|