Survey Results

19-Jan-09 3:17

Interestingly, the votes go to "depends on the situation", rather than random.

This means that most of us do have a strong preference, given a specific condition to test.
Or that most of us didn't read beyond the 3rd option.

Burning Chrome ^ | Linkify!| FoldWithUs! | sighist

Re: Well

Dan Suthar19-Jan-09 3:51

Dan Suthar

19-Jan-09 3:51

peterchen wrote:
Or that most of us didn't read beyond the 3rd option

I was also wondering that! Smile | :)

Re: Well

Mohm'ed Melhem19-Jan-09 8:11

Mohm'ed Melhem

19-Jan-09 8:11

I agree on 2ed one that most of them didn't read after 3ed option Sleepy | :zzz:

Whatever you do will be insignificant, but it is very important that you do it

Depends on the situation

peterchen19-Jan-09 2:33

Infidel! You return more than once from a routine!

19-Jan-09 2:33

The question is not really pointless, since there are people who have strong opinions about it (usually "always test for positive conditions"). Since I never had explained or understood the "why", I won't judge Smile | :)

My prime directives influencing the style of conditions are simplified reading (i.e. reading the code aloud is close to the condition I want to express), reduced nesting and testing cheaper conditions first. So it's e.g.

<br />
if (itemCount == 0) <br />
  return false;<br />
<br />
if (!file.Exists()) <br />
  return false;<br />
<br />
...<br />
<br />
return true;<br />

Burning Chrome ^ | Linkify!| FoldWithUs! | sighist

jhwurmbach19-Jan-09 3:07

jhwurmbach

19-Jan-09 3:07

You will burn on a stake for that!

While we were at strong opinions... Big Grin | :-D

Personally, I have no problem with multiple returns. But an amazing number of styleguides strongly forbid it - contrary to intuition and code readability, as I think.

Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"

Re: Infidel! You return more than once from a routine!

peterchen19-Jan-09 3:15

Re: Depends on the situation

19-Jan-09 3:15

It made sense in C / procedural style, where "one exit point" made sense for avoiding ressource management errors.

However in any modern language we have exceptions thwarting the effort anyway, and deterministic destructors/finalizers to deal with the problem.

Burning Chrome ^ | Linkify!| FoldWithUs! | sighist

sashoalm19-Jan-09 4:19

sashoalm

19-Jan-09 4:19

I like this style as well. Not only for the readability but also because it better reflects what the code is doing - it's making several tests whether it can safely go ahead with whatever action it's going to perform or if something's wrong and it should fail.

I hate it when if ... else ... if ... else ...... is used instead because it can confuse you by suggesting branching where there is none.

There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal

Re: Depends on the situation

Shog⁹19-Jan-09 4:39

Shog⁹

19-Jan-09 4:39

Agreed.

----

You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.

It depends

Graham Shanks19-Jan-09 2:25

Graham Shanks

19-Jan-09 2:25

It depends on the relative lengths of the then and else clauses. If both are short then I'm more likely to put the true clause first. If one if short (often because its an error case) and the other is long then the shorter one comes first. This makes it easier to determine which if statement a code block belongs to.

For instance

if(statement is false)
  return ERROR_CODE;
else
{
  // Long complicated piece of code
}

in preference to

if(statement is true)
{
  // A really long bit of code
}
else
{
  // By the time you get here its hard to see the iff statement
  return ERROR_CODE;
}

Of course, if both are long (or even if just one of them is long) I'd refactor the long code into functions, i.e.

if(statement is false)
  DoLongComplicatedStuff();
else
  DoOtherLongComplicatedStuff();

Graham

Librarians rule, Ook!

Brad Stiles19-Jan-09 3:36

Brad Stiles

19-Jan-09 3:36

For me it depends on the frequency of each of the outcomes. Which ever is likely to happen most often is the "if", and the less frequently encountered condition is the "else".

If they are equally likely, or nearly so, I tend to use the true case as the if, 'cause I don't usually like reading negative logic.

/bs

firegryphon19-Jan-09 13:24

firegryphon

19-Jan-09 13:24

Yours is my preferred method. Though sometimes there are cases that either the false or true statement just makes it easier to understand what is happening. In some cases where I have if..then..else but no case statements I'll handle the only definitive answer first and handle the opposite and "maybe" answers elsewhere.

ghle19-Jan-09 14:39

ghle

19-Jan-09 14:39

Graham Shanks wrote:

For instance

if(statement is false)
  return ERROR_CODE;
else
{
  // Long complicated piece of code
}

in preference to

if(statement is true)
{
  // A really long bit of code
}
else
{
  // By the time you get here its hard to see the iff statement
  return ERROR_CODE;
}

This should be rewritten as follows for clarity and reduced code size.

if(statement is false)
{
  return ERROR_CODE;
}
// Long complicated piece of code

There is NO ELSE.

Gary

Is this a trick question?

tsdragon19-Jan-09 23:56

tsdragon

19-Jan-09 23:56

And THAT makes it even easier to read! Good catch!

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

Michael Gage19-Jan-09 2:02

Michael Gage

19-Jan-09 2:02

if(areUsingTDD)
thisQuestionDoesntReallyMakeSense

Re: Is this a trick question?

peterchen19-Jan-09 2:34

19-Jan-09 2:34

How does TDD fit in here?
You don't use coditions in TDD? Big Grin | :-D

Burning Chrome ^ | Linkify!| FoldWithUs! | sighist

Always FALSE first

Paul Darlington19-Jan-09 1:56

Paul Darlington

19-Jan-09 1:56

because where boolean types are supported only by integers then FALSE is always zero but TRUE can be 1, -1, 42 or anything that is not zero thus relying on TRUE to be one, and I have seen lots of old code that does, can lead to a world of pain and despair.

MatrixDud19-Jan-09 5:20

MatrixDud

19-Jan-09 5:20

But in those cases it is better to test for non-zero instead of TRUE.

BOOL bAnswer = ReturnOfSomeFunction();
if( bAnswer != 0 ) {
do something;
}

Paul Darlington19-Jan-09 5:25

Paul Darlington

19-Jan-09 5:25

That was exactly the point I tried to make. Tests on TRUE can be unreliable, Tests on FALSE that might well be stated as !FALSE or NOT FALSE can usually be relied upon. Hence my response to the survey test FALSE first.

MatrixDud20-Jan-09 11:14

MatrixDud

20-Jan-09 11:14

But of course that only pertains to the Microsoft BOOL variable and not bool in C++. C did not actually have a bool value defined until C99. BOOL is actually an INT (sizeof(BOOL) = 4 or 8 on x64) whereas bool is a byte (sizeof(bool) = 1). Most languages use a built in type of bool that is one byte and only capable of being true or false (1 or 0). The proper use of BOOL is to test if it is non-zero for TRUE with most functions that return BOOL. Some functions that return BOOL will actually return more than just 2 possible answers (ie: 0 for success or a value representing a return or error code).