Prev: CONVERT TO ISLAM OR DIE. ALLAH AKBAR!!
Next: C18 Compiler again
From: Chris Burrows on 8 Jun 2010 19:02
"rickman" <gnuarm(a)gmail.com> wrote in message
news:a6bc47dd-7e3e-4930-b049-648ed65f1dfd(a)r27g2000yqb.googlegroups.com...

The ability to spot an exit point is a different issue than having one
vs. multiple exit points. Yes, I will agree that having multiple
exits can make the code harder to read, but the key word here is
"can". In the "real world", coding is done by humans and humans can
determine when to follow guidelines and when to break them. The code
being discussed is a perfect example of when multiple returns can be
perfectly clear.

---

The problem with the code being discussed is that it is highly contrived and
not a good representation of real-world situations. I suspect it is from a
class exercise. If so it could easily mislead the student into thinking that
multiple returns are better than an if-then-else ladder in the general case.


From: Paul Keinanen on 9 Jun 2010 01:34
On Tue, 08 Jun 2010 09:15:04 +0200, David Brown
<david(a)westcontrol.removethisbit.com> wrote:

>You must read and understand functions and their flow of control before
>you modify them. A coding style that makes it easier to read and
>understand the functions therefore makes maintenance easier. So if
>multiple returns makes the code clearer, it's a good thing.
>
>As an example, consider the very common template:
>
>void foo(int *p) {
> if (!p) return;
> ... do something with *p
>}

It is a good idea to check all those parameters immediately at entry
that can be checked at that stage and return immediately if test
failed. Things that can be checked at this stage are for instance
checks against null pointers, values used as indexes etc.

When writing kernel mode services, it is extremely important to check
that the parameters could actually have been accessed from the calling
(usually user mode) address space. Failing to do these tests properly
caused a lot of crashes for instance on early NT4 versions, when part
of the graphical user interface was moved from user mode to kernel
mode to avoid the overhead of frequent user/kernel/user mode changes
in NT3.51.

Getting rid of those pathological cases immediately in the beginning
will simplify the rest of the code, when there is no need to test for
pointer validity or index validity for these time each time a variable
is accessed and avoids multiple error handling code within the actual
function body.

>
>That is clearer than:
>
>void foo(int *p) {
> if (p) {
> ... do something with *p
> }
>}
>
>The first version removes an extra layer of block indents, making the
>function slightly flatter and slightly clearer.

From: Paul Carpenter on 9 Jun 2010 03:13
In article <4h8u06hr7sb4fmgld0quotvrc96p8i9t9d(a)4ax.com>, keinanen(a)sci.fi
says...
> On Tue, 08 Jun 2010 09:15:04 +0200, David Brown
> <david(a)westcontrol.removethisbit.com> wrote:
>
> >You must read and understand functions and their flow of control before
> >you modify them. A coding style that makes it easier to read and
> >understand the functions therefore makes maintenance easier. So if
> >multiple returns makes the code clearer, it's a good thing.
> >
> >As an example, consider the very common template:
> >
> >void foo(int *p) {
> > if (!p) return;
> > ... do something with *p
> >}
>
> It is a good idea to check all those parameters immediately at entry
> that can be checked at that stage and return immediately if test
> failed. Things that can be checked at this stage are for instance
> checks against null pointers, values used as indexes etc.
......

Very good point and saves often quite a bit of processing time.

The one thing on readability and conditionals I rarely see pointed
out or used, is the case where inverting the conditional WILL make
the code more readable and LESS likely to miss return statements.

Compare -

void foo(int *p, int q)
{
if (p);
... for 50+ lines do something with *p
else
... couple of lines set some default values or return

... for 50+ lines do something else with q and earlier results
}

With

void foo(int *p, int q)
{
if (!p);
... couple of lines set some default values or return
else
... for 50+ lines do something with *p

... for 50+ lines do something else with q and earlier results
}

The first I often see and the various loops and sub-blocks in that
section can make it difficult to see which block or conditional the
return is associated with.

--
Paul Carpenter | paul(a)pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: CONVERT TO ISLAM OR DIE. ALLAH AKBAR!!
Next: C18 Compiler again