|
Still: Yuck!
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
agreed. that is just a nasty example of embedded logic.
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
|
|
|
|
|
|
That would depend on whether I return a value or not.
On a related note, K&R or Allman?
|
|
|
|
|
Whitesmiths.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I did expect that answer. 
|
|
|
|
|
You're a monster
Allman ftw.
|
|
|
|
|
Under most circumstances, a single return is best. But ... I much prefer this:
void MyFunc ()
{
if (!ValidateUserInput(ATextBox.Text))
{
TellUserAboutTheProblem();
return;
}
if (!ValidateUserInput(AnotherTextBox.Text))
{
TellUserAboutTheProblem();
return;
}
...
}To this:
void MyFunc ()
{
if (!ValidateUserInput(ATextBox.Text))
{
TellUserAboutTheProblem();
}
else if (!ValidateUserInput(AnotherTextBox.Text))
{
TellUserAboutTheProblem();
}
else
{
...
}
}And sometimes the best thing to do is just return, particularly from a nested loop:
for (int i = 0; i < 100; i++)
{
for (int j = 0; j < 100; j++)
{
if (myArray[i, j] == value) return true;
}
}
return false;Any other mechanism is just making it more complicated, not less.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That's the longer and much better version of what i couldn't bother to write down. 
|
|
|
|
|
I thought you were joking when you said Whitesmiths!
for()
{
for()
Really hurts my eyes 
for()
{
for()
I like.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
You are welcome to your opinion*, but I like the way it's consistent: the indentation is the whole of the relevant block of code:
if (a)
b;
if (a)
{
b;
c;
}Instead of the inconsistent Allman:
if (a)
b;
if (a)
{
b;
c;
}
* As long as your opinion doesn't include using 1TB, of course.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I have been brainwashed to NEVER do:
if (a)
b;
I think the preference is a matter of taste. I don't find either alternative more "consistent". "Consistent" depends on how you define that word (and the words "relevant code"). When skimming over large blocks of code the braces are - for my eyes - easier to find Allman style.
And the b; is very slightly easier on my eye in your Allman example. My guess is that we prefer what we were exposed to when we started walking... coding...
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
|
OriginalGriff wrote: void MyFunc ()
{
if (!ValidateUserInput(ATextBox.Text))
{
TellUserAboutTheProblem();
}
else if (!ValidateUserInput(AnotherTextBox.Text))
{
TellUserAboutTheProblem();
}
else
{
...
}
}
One of my first program was this. Luckily I started coming here and learned how to do it better 
|
|
|
|
|
sort of depends on what I call the "story"
if the story says "if X is null or is [example] an empty list then stop processing" = in my mind early return.
if the story says "do thus-ad-that to the contents of X" - to save on errors naturally check X for null/empty makes sense - then of course it's if (X != null) ...
Forogar wrote: ntroduces an execution statement (return) on the same line as the "if" which is bad coding practice
?????????????? bad coding practice ????????????????? huh?
Nothing is wrong, nor bad, nor unsafe with that code, it is perfectly good code.
you confuse practice with style: style is subjective, "bad practice" increases the chance for error or failure.
personally I dislike code that runs too many pages, so I often put short single statements and opening braces on the same line as the if (), while () etc. (Coming from K&R style C background.) and I like ....
AND SO, before you say it, I'll say it for you:
--- you think my style is ugly.
Well guess what:
---- I think your style is ugly.
AND WHO CARES!!
1. it's the code that matters, NOT THE STYLE,
2. different style IS NOT BAD PRACTICE weather you like it or not.
(please don't bring up "readability" bullshit, I find more compact more readable, please don't bring up "industry standard" - my K&R background, and I'm not the only one doing it that way.)
3. you can have the editor re-format [to your preferred] style on one keystroke, so even more WHO CARES.
nuff said.
Message Signature
(Click to edit ->)
|
|
|
|
|
If you have dealt with Unix fanboys, you'll now doubt have encountered the stupid "which hacky character shall we use for white space: spaces or tabs?". The correct answer is "whatever the team is using, I format it to that before committing".
As for consistency, I only really am a stickler with f***ing braces. I've seen too many recurrent bugs because a programmer is cute and makes a braceless if. Then the next one comes in, adds one more call and doesn't realise the braces are gone. Ooops, billion dollar bug introduced. Nasty and no need.
|
|
|
|
|
Oh I hear you on the *nix, but as often it's the text editor that mixes spaces with tabs; i.e.
1. <return><tab> inserts a tab
... but then some editors change it to spaces, some don't...
2. <return><8 spaces>, inserts spaces
... but then some editors change that to a tab, some don't
and for more fun if it's an existing source file, some editors change only the edited lines to/from tabs and leave the untouched lines as they were, and some don't. Arrggh
(doing some C programming on Linux, pulling down code snippets, getting lots of both tab and space.)
So anyway don't blame the *nix fanbois, it's the [history of their] tools.
Worked at one company, the system admin decided the standard tab size would be 3 spaces and forced everybody to set the vi editor to honor this - All fine, except when they got source from outside the company set with the standard tab size of 8. Talk about moaning on and on, and when I suggested they really should use the standard size that everyone else on the planet used, "oh no, we won't change, it's everybody else that should change." ... idiots.
as to curly braces (and statements on same line as the if ()), as mentioned I'll normally only not use for very simple single statements, i.e. mostly return, break, continue, or perhaps a single method/function call on it's own.
i.e. "if (x == 0) return;" it's pretty clear if you want to add a statement before the return that the curlies aren't there.
anything longer (even if it's only a single function/method call but with many or long arguments) just like you I'll multi-line and wrap it in curlies for safety.)
as said it's my style, not going to claim it's better or worse than another's style.
Message Signature
(Click to edit ->)
|
|
|
|
|
Simply do it how you think it's ok. As long as it's only a question of preferences, I see no salomonian compromise.
Why?
Let's assume you can keep the method short and to the point, with only few conditions that 'spaghettify' the code. In that case I hope that all people involved are intelligent enough to read the code, despite it not having their preferred format.
In the other case, hopefully rare, where you have no choice and the method gets a little longer and has many if/else conditions, then religiously trying to put it in a certain format will most probably 'spaghettify' it even more and make it even harder to understand.
That's why I always prefer good judgement over religiously (meaning thoughtlessly) enforcing 'standards' at all cost. Whose standards? Those of the team as a common ground or those of a few beaurocrats who never find an end?
Been there, done that. I was once in charge of writing the 'rulebook' and code review. It kept getting longer every week. Rules, more rules, exceptions to the rules and then of course alternate rules. In the end it was always one or two people who turned the code review into a discussion about their personal preferences while the rest of the team started to ignore the whole worthless circus and automatically getting the buerocrats off their backs by giving them so much to freak out about that even they could not keep up with inventing more 'standards'. If those idiots want someone to type exactly what they want, why don't they get themselves a secretary?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
The (professional) opinion is that humans work better with "positive" statements vs deciphering compound negatives.
I will even resort to:
if ( a && b && c ){
// continue.
} else {
return;
}
... for myself.
("Early returns" probably run contrary to the notion of "diving into the code"; but since code should not run more than "a page", "diving" implies a bigger problem).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 15-Feb-19 13:57pm.
|
|
|
|
|
I believe I am in the minority on this but I prefer one single return statement. Multiple returns adds unnecessary confusion. For example, if you put a breakpoint near the end of a function and it never hits it may be because of the early returns so you have to go hunting around to find out what's going on.
One return.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Putting a break point that does not get hit where you expect it to only implies that one does not understand the program flow; not that there could be "too many returns".
Without a try-catch block everywhere, every exception amounts to an "early return".
Also, "early returns" facilitate the returning of different "condition codes"; instead of "tramping" them along.
A la IBM;
0 - Good
4 - Good with conditions
8 - Warning
16 - Oh Oh
...
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: only implies that one does not understand the program flow;
Exactly! 
But it's very easy to assume the code is failing down near the bottom of the function and therefore you put the breakpoint there because you don't want to step through all of it.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Nice and well, until you sit in the middle of several levels of conditions, something goes wrong and you want to get out of there. What then? Awkward nested if/else blocks? Or do we just make use of the good old GOTO to hop to your single return at the end? I do exactly that often enough in assembly programs, just because I need a single return as a point where I clean up the stack frame before actually returning. I don't really see the point if it's only a matter of principle.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: something goes wrong and you want to get out of there
That's when you throw an exception.
CodeWraith wrote: Awkward nested if/else blocks?
Maybe breaking things into functions would be better.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
ZurdoDev wrote: That's when you throw an exception.
In what way is that better than an early return if your goal is to have a single return point? And catching it yourself at the end of your function does not justify the overhead of throwing an exception. The dreaded GOTO would then be cheaper and no more or less problematic.
ZurdoDev wrote: Maybe breaking things into functions would be better.
Unless you can't afford to bog down the processor with too much overhead of packing parameters onto the stack or cleaning it up afterwards. On a strong processor that's no big deal anymore, but often enough I sit there with a C compiler and a small microcontroller clocked < 10 MHz. Usually some output pins need to be pulled up or down according to a certain timing, leaving me only a few machine instructions on the microcontroller within that timeframe. In that case I may have to resort to inline assembly and can't afford any function calls.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
