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 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 context. Can you not avoid the
ifentirely? :-D Is that called in a tight loop? As presented, I'd stick with the first example. -
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 SubscriptionsWell, maybe this is a trick question, but ... I read and understood the first one immediately. About as quickly as I read it. The second one...I'm still not exactly sure about it. I guess it's all a state of mind. If you like objective, try #1. If you like subjective, try #2. :rolleyes:
-
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 Subscriptionssecond one. reduces the amount of potential if statements to just one. first one is easier to understand and read, I admit.
-
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
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
-
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 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:
Copy Code
MaybeDoSomething(foo);
...
void MaybeDoSomething(bool foo)
{
if (foo)
{
// do the something, and do something else.
}
}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 Subscriptionsfoo ? DoSomething() : ;:-D Simpler is better!The Science of King David's Court | Object Oriented Programming with C++
-
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 SubscriptionsNot 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.
-
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 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
-
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'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!
-
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.
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 SubscriptionsTrue 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
-
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
