Which do you prefer? A programming question!

YahiaEQ

Depends 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).

Delphi 7 Solutions

from 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

BryanFazekas

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.

Kirk 10389821

this 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]

Gary Wheeler

I don't like the idea of having a DoSomething() and a MaybeDoSomething that only adds a simple if {...} around a call. My approach would have been:

void DoSomething(bool something_allowed)
{
if (something_allowed)
{
// logic from original DoSomething()
}
}

I've worked with code that was written such that there is only one or two block constructs per method. Naming ends up stupid (OpenFileIfFoundAndNotAlreadyOpen(), anyone?), and it makes it very difficult to follow logic. I would much rather have a method run a little longer yet be able to see the entire algorithm in one place.

Software Zen: delete this;

Alister Morton

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.

David ONeil

Obfuscated is when you use partial template specialization for the task! :laugh:

The Science of King David's Court | Object Oriented Programming with C++

honey the codewitch

it wasn't me, i swear! *hides*

Real programmers use butterflies

Daniel Pfeffer

:omg: :wtf: X|

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.

thewazz

Aka single resp.

Reelix

The first one. Why are you even calling the second one if you're not going to use it?

-= Reelix =-

sasadler

First one.

charlieg

Depends on the complexity of the method containing #1. I prefer showing logic as soon as possible *in context*. I'm also a big believer in encapsulation for the soul purpose of containing the application in edible portions.

Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759

r_hyde

First option, full stop. -but- Here's a fun little twist, if your language of choice supports this sort of thing (I'll use C# to illustrate):

void ExecuteIf(Func predicate, Action thingToExecute)
{
if (predicate())
thingToExecute();
}

ExecuteIf(() => foo, DoSomething);

...but I'm not convinced that this is any easier to read, it imposes a little extra overhead, and I would still stick with your first option. Just wanted to throw it into the mix :cool:

Lost User

The 2nd option is like eating something you shouldn't.

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food

Martin ISDN

if (foo)
{
DoSomething();
}

avoid the function call if not necessary. what you see is what it does.

AnotherKen

The first is more simple and will run faster when compiled. However, the second might be preferable if you plan to run that bit of code a lot of times since then you just re-type one call and it makes the code easier to read.

rjmoses

It depends! 1) If the section of code is executed frequently, then #2 adds the cpu overhead of the call/return therefore slowing the program down. 2) If the DoSomething code is relatively simple and is only used in this one location, then it should be coded in place in order to make readability, understandability and comprehension better. 3) If the Dosomething code is frequently used code, then #1 makes it clearer when something is done. The answer to this question is a choice of balancing performance vs readability vs understandability vs comprehension. To me, code should always be written such that I or anyone else can comprehend the intent and methodology of the original programmer in a few seconds.

User 14060113

The answer is a clear "Depends!" ;-)

PSU Steve

First. I prefer only calling logic when the situation warrants. You always call MaybeDoSomething in the second, even if it really does nothing...