From: D Yuniskis on
Hi Vladimir,

Vladimir Vassilevsky wrote:
> kishor wrote:
>> I have some doubt in using "if" "else" statements.
>> Which is the better method (for efficiency, readability or any other
>> reason)????.
>
> A piece of code shall have only one entry point and only one exit point.

As with most "coding rules", I *really* disagree with that! :>
(I've made a goal of routinely loosening all of the "rules"
that I've previously thought to have been "written in stone")

Write the code so it is easy to understand. Don't
force extra *syntax* on the code just to make it fit
some (well intended, though arbitrary) rule.

E.g., how do you handle:

void
task(void) {
while (FOREVER) {
lamp(ON);
sleep(ON_TIME);
lamp(OFF);
sleep(OFF_TIME);
}
}

and still satisfy the "shall" in your rule?
From: rickman on
There is one other way to write this that I tend to use when coding.
One of the "guides" to coding I read many years ago, perhaps in
college said the smaller of the two choices in an if then else should
be first. This makes it easier for the eye to scan the code and glean
structure from the shape... a bit like the way I learned to read...
look for the outline of the words rather than parsing every letter.

Also,, it is not uncommon for the else and the if to be put on the
same line to show that the "if" is the only statement within the
else. The result is very clean, simple and uses much less space
streamlining the code to the point that the structure is very clear to
the eye. Oh, and you don't need all those parens for single
statements.

uint16_t Func1(uint16_t int1, uint16_t int2, uint16_t int3)
{
if (int1 != 32)
return 3;
else if (int2 != 16)
return 2;
else if (int3 != 8)
return 1;
else
return 0;
}

Rick


On Jun 7, 4:49 am, kishor <kiis...(a)gmail.com> wrote:
> Hi friends,
>
> I have some doubt in using "if" "else" statements.
>
> uint16_t Func1(uint16_t int1, uint16_t int2, uint16_t int3)
> {
>
>         if(int1 == 32)
>         {
>                 if(int2 == 16)
>                 {
>                         if(int3 == 8)
>                         {
>                                 return 0;
>                         }
>                         else
>                         {
>                                 return 1;
>                         }
>                 }
>                 else
>                 {
>                         return 2;
>                 }
>         }
>         else
>         {
>                 return 3;
>         }
>
> }
>
>   =======================  OR  ==============================
>
> uint16_t Func1(uint16_t int1, uint16_t int2, uint16_t int3)
> {
>         if(int1 != 32)
>         {
>                 return 3;
>         }
>
>         if(int2 != 16)
>         {
>                 return 2;
>         }
>
>         if(int3 != 8)
>         {
>                 return 1;
>         }
>
>         return 0;
>
> }
>
> Which is the better method (for efficiency, readability or any other
> reason)????.
>
> Thanks & Regards,
> Kishore.

From: rickman on
On Jun 7, 8:48 am, Vladimir Vassilevsky <nos...(a)nowhere.com> wrote:
> kishor wrote:
> > Hi friends,
>
> > I have some doubt in using "if" "else" statements.
> > Which is the better method (for efficiency, readability or any other
> > reason)????.
>
> A piece of code shall have only one entry point and only one exit point.
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com

Only small minds follow rules blindly. The reason for this rule is to
facilitate debugging and allow breakpoints to be set at the single
exit of a routine. All of the tools I have used all me to set a
breakpoint at the final semicolon which is where the actual exit from
the routine is found.

Rick
From: David Brown on
On 07/06/2010 14:48, Vladimir Vassilevsky wrote:
>
>
> kishor wrote:
>> Hi friends,
>>
>> I have some doubt in using "if" "else" statements.
>> Which is the better method (for efficiency, readability or any other
>> reason)????.
>
> A piece of code shall have only one entry point and only one exit point.
>

A piece of code shall have only one entry point unless it is a
coroutine, which is fairly specialised programming because C doesn't
support coroutines well.

A piece of code shall have only one exit point unless it is clearer and
neater to have more than one exit.

In my mind, the neatest way to write this code is:

uint16_t Func1(uint16_t int1, uint16_t int2, uint16_t int3) {
if (int1 != 32) return 3;
if (int2 != 16) return 2;
if (int3 != 8) return 1;
return 0;
}

Of course, parameter names and the various numbers should be replaced by
sensible names and symbolic constants, and you may need comments (if the
names are not clear enough).

That breaks another rule of good C programming - /always/ use brackets
with "if" statements. But by being neat and compact, it is easy to see
what is going on - and that trumps most other rules.

From: Boudewijn Dijkstra on
Op Mon, 07 Jun 2010 14:59:57 +0200 schreef D Yuniskis
<not.going.to.be(a)seen.com>:
> Vladimir Vassilevsky wrote:
>> kishor wrote:
>>> I have some doubt in using "if" "else" statements.
>>> Which is the better method (for efficiency, readability or any other
>>> reason)????.
>> A piece of code shall have only one entry point and only one exit
>> point.
>
> As with most "coding rules", I *really* disagree with that! :>
> (I've made a goal of routinely loosening all of the "rules"
> that I've previously thought to have been "written in stone")
>
> Write the code so it is easy to understand. Don't
> force extra *syntax* on the code just to make it fit
> some (well intended, though arbitrary) rule.
>
> E.g., how do you handle:
>
> void
> task(void) {
> while (FOREVER) {
> lamp(ON);
> sleep(ON_TIME);
> lamp(OFF);
> sleep(OFF_TIME);
> }
> }
>
> and still satisfy the "shall" in your rule?

static void
callback_on(void) {
lamp(ON);
timer(callback_off, ON_TIME);
}

static void
callback_off(void) {
lamp(OFF);
timer(callback_on, OFF_TIME);
}

void
main(void) {
callback_on();
}


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)