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 SubscriptionsI don't like the idea of having a
DoSomething()and aMaybeDoSomethingthat only adds a simpleif {...}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; -
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 SubscriptionsIf 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.
-
: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.
Obfuscated is when you use partial template specialization for the task! :laugh:
The Science of King David's Court | Object Oriented Programming with C++
-
Obfuscated is when you use partial template specialization for the task! :laugh:
The Science of King David's Court | Object Oriented Programming with C++
it wasn't me, i swear! *hides*
Real programmers use butterflies
-
Obfuscated is when you use partial template specialization for the task! :laugh:
The Science of King David's Court | Object Oriented Programming with C++
: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.
-
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!
-
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 SubscriptionsDepends 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
-
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 SubscriptionsFirst 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:
-
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 Subscriptionsif (foo)
{
DoSomething();
}avoid the function call if not necessary. what you see is what it does.
-
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 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.
-
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! 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.
-
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 answer is a clear "Depends!" ;-)
-
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 -
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 SubscriptionsThat is a different situation than posed. The overhead of a function call could be justified in this case.
