Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > cascading ifs--style question

Reply
Thread Tools

cascading ifs--style question

 
 
William Pursell
Guest
Posts: n/a
 
      11-16-2007
Lots of discussion lately on coding so that the debugger
stops on each line, and this is yet another. In that debate,
I fall in the camp of those who like code written such that
every statement is on a separate line (although I can't
stop using ). I am curious to get opinions on the following
style:

instead of:
if( a && b )
foo();

use:
if( a )
if( b )
foo();

This style puts the conditionals on separate lines, so it
has that in its favor. But me thinks it has very few other
redeeming features and is a bit ugly.

Your thoughts?

 
Reply With Quote
 
 
 
 
user923005
Guest
Posts: n/a
 
      11-16-2007
On Nov 15, 8:26 pm, William Pursell <(E-Mail Removed)> wrote:
> Lots of discussion lately on coding so that the debugger
> stops on each line, and this is yet another. In that debate,
> I fall in the camp of those who like code written such that
> every statement is on a separate line (although I can't
> stop using ). I am curious to get opinions on the following
> style:
>
> instead of:
> if( a && b )
> foo();
>
> use:
> if( a )
> if( b )
> foo();
>
> This style puts the conditionals on separate lines, so it
> has that in its favor. But me thinks it has very few other
> redeeming features and is a bit ugly.
>
> Your thoughts?


I think it is a mistake to code so that the debugger is happy.

Write it the way that is the most clear. If alternatives are
absolutely equal in your eyes, then choose the one you like (including
the one that makes the debugger happy).
 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      11-16-2007
William Pursell wrote, On 16/11/07 04:26:
> Lots of discussion lately on coding so that the debugger
> stops on each line, and this is yet another. In that debate,
> I fall in the camp of those who like code written such that
> every statement is on a separate line (although I can't
> stop using ). I am curious to get opinions on the following
> style:
>
> instead of:
> if( a && b )
> foo();
>
> use:
> if( a )
> if( b )
> foo();
>
> This style puts the conditionals on separate lines, so it
> has that in its favor. But me thinks it has very few other
> redeeming features and is a bit ugly.
>
> Your thoughts?


Firstly, I believe in making the code debugger friendly, but only where
it does not make it human unfriendly.

I agree that it is ugly. If it is not function calls you can easily
check the condition of all the variables and sub-expression so you can
see why it has taken or not taken the branch. If b was a function call
there would be more of an argument for separating it out, but not
necessarily conclusive.

Considering all that, I would use the first form.
--
Flash Gordon
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      11-16-2007
Ugly.

while(x && y);

would become

if(x)
while(y)
if(!x)
break;
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-16-2007
William Pursell wrote:
> Lots of discussion lately on coding so that the debugger
> stops on each line, and this is yet another. In that debate,
> I fall in the camp of those who like code written such that
> every statement is on a separate line (although I can't
> stop using ). I am curious to get opinions on the following
> style:
>
> instead of:
> if( a && b )
> foo();
>
> use:
> if( a )
> if( b )
> foo();
>
> This style puts the conditionals on separate lines, so it
> has that in its favor. But me thinks it has very few other
> redeeming features and is a bit ugly.


If the sub-conditions are really ``a'' and ``b'' (i.e., simple references to
variables), then it doesn't make any difference. If they're, say, function
calls then you can assign them to temporaries.

For example, rather than this:

if (func1() && func2()) ...

you might write this:

int cond1 = func1();
int cond2 = func2();
if (cond1 && cond2) ...

This might be even more readable than the original if you choose sufficiently
descriptive names for the temporaries.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      11-16-2007
"Keith Thompson" <(E-Mail Removed)> schrieb im Newsbeitrag
news:fhk5cb$9ga$(E-Mail Removed)...
> William Pursell wrote:
>> Lots of discussion lately on coding so that the debugger
>> stops on each line, and this is yet another. In that debate,
>> I fall in the camp of those who like code written such that
>> every statement is on a separate line (although I can't
>> stop using ). I am curious to get opinions on the following
>> style:
>>
>> instead of:
>> if( a && b )
>> foo();
>>
>> use:
>> if( a )
>> if( b )
>> foo();
>>
>> This style puts the conditionals on separate lines, so it
>> has that in its favor. But me thinks it has very few other
>> redeeming features and is a bit ugly.

>
> If the sub-conditions are really ``a'' and ``b'' (i.e., simple references
> to variables), then it doesn't make any difference. If they're, say,
> function calls then you can assign them to temporaries.
>
> For example, rather than this:
>
> if (func1() && func2()) ...
>
> you might write this:
>
> int cond1 = func1();
> int cond2 = func2();
> if (cond1 && cond2) ...
>
> This might be even more readable than the original if you choose
> sufficiently descriptive names for the temporaries.

But is is not the same. In the 1st case func2() may or may not be called,
depeding on the restult of func1(), in the 2nd it will always be called.

Bye, Jojo


 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      11-16-2007
user923005 <(E-Mail Removed)> writes:

> On Nov 15, 8:26 pm, William Pursell <(E-Mail Removed)> wrote:
>> Lots of discussion lately on coding so that the debugger
>> stops on each line, and this is yet another. In that debate,
>> I fall in the camp of those who like code written such that
>> every statement is on a separate line (although I can't
>> stop using ). I am curious to get opinions on the following
>> style:
>>
>> instead of:
>> if( a && b )
>> foo();
>>
>> use:
>> if( a )
>> if( b )
>> foo();
>>
>> This style puts the conditionals on separate lines, so it
>> has that in its favor. But me thinks it has very few other
>> redeeming features and is a bit ugly.
>>
>> Your thoughts?

>
> I think it is a mistake to code so that the debugger is happy.


Debugger happy is normally reader happy too.
>
> Write it the way that is the most clear. If alternatives are
> absolutely equal in your eyes, then choose the one you like (including
> the one that makes the debugger happy).


Assuming a and b were expressions I would have at first glance:

aFlag = a();
bFlag = b();

if (aFlag && bFlag)
foo();

We can set watch/break points on conditions for aFlag and bFlag (e.g
only break if aFLag is true and bFlag is false.

But at second glance we realise that (a && b) might be too clever for our
own good. C will not evaluate b() if a() evaluates to false ....

So as the writer of the ORIGINAL code I would have, to make it explicit
what I meant

if(a())
if(b()) /* optimized so as not to call b() if a() fails */
foo();

This is also debugger friendly as we can set a break on the second if().

We could do the intermediate flag trick if we wanted to break on a()
failing(returning false). We can already set a break on foo() when both
conditions are passed.

It is always worth considering debugger/reader friendly code. People
will thank you in the long run.

 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      11-16-2007
William Pursell wrote:
>
> Lots of discussion lately on coding so that the debugger
> stops on each line, and this is yet another. In that debate,
> I fall in the camp of those who like code written such that
> every statement is on a separate line (although I can't
> stop using ). I am curious to get opinions on the following
> style:
>
> instead of:
> if( a && b )
> foo();
>
> use:
> if( a )
> if( b )
> foo();
>
> This style puts the conditionals on separate lines, so it
> has that in its favor. But me thinks it has very few other
> redeeming features and is a bit ugly.
>
> Your thoughts?


Consider, too, the implitations of an else in the above. How
would you handle converting:

if ( a && b )
foo();
else
bar();

to your "debugger friendly" version?

And, I assume you don't really mean "a separate line", because
that would , to me, mean something like this:

if ( a
&& b
)
foo();

Though I have to admit I use such things when the condition gets
complex.

if ( ( some_long_condition
||
another_long_condition
)
&&
yet_another_condition
)
{
do_something;
}

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <(E-Mail Removed)>


 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      11-16-2007
Keith Thompson wrote:
[...]
> For example, rather than this:
>
> if (func1() && func2()) ...
>
> you might write this:
>
> int cond1 = func1();
> int cond2 = func2();
> if (cond1 && cond2) ...
>
> This might be even more readable than the original if you choose sufficiently
> descriptive names for the temporaries.


This isn't the same. If func1() returns zero, func2() wouldn't be
called in the original case.

Consider:

if ( pointer != NULL && *pointer != 0 )

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <(E-Mail Removed)>

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      11-16-2007
Richard wrote, On 16/11/07 13:39:
> user923005 <(E-Mail Removed)> writes:
>
>> On Nov 15, 8:26 pm, William Pursell <(E-Mail Removed)> wrote:
>>> Lots of discussion lately on coding so that the debugger
>>> stops on each line, and this is yet another. In that debate,
>>> I fall in the camp of those who like code written such that
>>> every statement is on a separate line (although I can't
>>> stop using ). I am curious to get opinions on the following
>>> style:
>>>
>>> instead of:
>>> if( a && b )
>>> foo();
>>>
>>> use:
>>> if( a )
>>> if( b )
>>> foo();
>>>
>>> This style puts the conditionals on separate lines, so it
>>> has that in its favor. But me thinks it has very few other
>>> redeeming features and is a bit ugly.
>>>
>>> Your thoughts?

>> I think it is a mistake to code so that the debugger is happy.

>
> Debugger happy is normally reader happy too.


Normally, possibly, but definitely not always.

>> Write it the way that is the most clear. If alternatives are
>> absolutely equal in your eyes, then choose the one you like (including
>> the one that makes the debugger happy).

>
> Assuming a and b were expressions I would have at first glance:
>
> aFlag = a();
> bFlag = b();
>
> if (aFlag && bFlag)
> foo();


Which behaves differently.

> We can set watch/break points on conditions for aFlag and bFlag (e.g
> only break if aFLag is true and bFlag is false.


If I needed to do that in debugging I might well make it
if (aflag=a() && bflag=b())
foo();

> But at second glance we realise that (a && b) might be too clever for our
> own good. C will not evaluate b() if a() evaluates to false ....


It does not take me more than one glance. Also as a lot of C code (and
code in other languages) relies on the short-circuit evaluation I would
say that anyone not comfortable with it is not suitable for work on most
C code.

> So as the writer of the ORIGINAL code I would have, to make it explicit
> what I meant
>
> if(a())
> if(b()) /* optimized so as not to call b() if a() fails */
> foo();


This would take me longer to read.

> This is also debugger friendly as we can set a break on the second if().
>
> We could do the intermediate flag trick if we wanted to break on a()
> failing(returning false). We can already set a break on foo() when both
> conditions are passed.


See comment above about using flags with the original format.

> It is always worth considering debugger/reader friendly code. People
> will thank you in the long run.


Debugger and reader friendly are not always the same, and I find your
alternatives to the original less readable. Someone without much
experience might find your alternatives more readable, but in my opinion
they need to be comfortable with the original to be able to maintain C
code anyway.
--
Flash Gordon
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cascading menu question Angus Javascript 6 01-11-2008 07:59 PM
Multiple cascading router question racerdog Computer Support 5 04-12-2007 04:13 PM
Cascading DropDownLists Question (non-Ajax) Don Miller ASP .Net 0 01-23-2007 05:49 PM
Cascading Style Sheets (CSS) question- LI items in horizontal display bbcrock@gmail.com HTML 2 01-31-2006 01:59 AM
Port SPAN cascading Chris Cisco 0 12-01-2003 07:22 PM



Advertisments