|
The first one.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I 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.
|
|
|
|
|
It 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
|
|
|
|
|
Option 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.
|
|
|
|
|
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).
|
|
|
|
|
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
|
|
|
|
|
this reminds me of a code review comment I received, for using:
while (true)
{
failure_code = 123;
if (failure_condition1) break;
failure_code = 125;
if (failure_condition2) break;
...
failure_code = 0; 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]
|
|
|
|
|
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)
{
}
}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;
|
|
|
|
|
The first one.
Why are you even calling the second one if you're not going to use it?
-= Reelix =-
|
|
|
|
|
|
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
|
|
|
|
|
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<bool> 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 
|
|
|
|
|
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
|
|
|
|
|
if (foo)
{
DoSomething();
}
avoid the function call if not necessary. what you see is what it does.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
The answer is a clear "Depends!" 
|
|
|
|
|
First. I prefer only calling logic when the situation warrants. You always call MaybeDoSomething in the second, even if it really does nothing...
|
|
|
|
|
Should you never trust stairs, because they are always up to something?
"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!
|
|
|
|
|
You can only trust them when you're at the bottom. Then they're only on the up and up.
Keep Calm and Carry On
|
|
|
|
|
Well that escalated quickly!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
There's always a down side.
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
|
|
|
|
|
Rail-y, watch your step with this one or you may not find the landing you hoped for!
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
|
Don't stare at that too long!
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
