attack of silly coding standard?

[Student]

Hello Everyone,

I'd like to know you professional opinion on following coding rule
freshly
imposed by my beloved employer:
"Thou shalt not have multiple returns from function"

Personally i hardly understand that one, apart from "readability"
argument
which i would hardly qualify as sufficent to impose such rule.
When i think about it i found the exact opposite true, that multiple
returns
improve readability

Best regards,
Mojmir

Those idiots who enforce such stupid rules have no idea of OOP.

 

[Juha Nieminen]

I'm going to disagree with most posters here and say that I tend to
avoid multiple returns as they do reduce readability.

I think you are confuing "early returns *can* make the code less
readable" with "early returns reduce readability". Not the same thing.

 

[Öö Tiib]

It does if you consider the rule itself as part of C++'s OOP too. But
why would you would consider either the single exit rule, or RAII to be
an OOP concept?

You consider idiom only as a way to achieve some concept. RAII is
useful idiom of encapsulation. Resources are always bound to
(automatic) lifetime management of some object. Encapsulation is one
of most fundamental concepts of object oriented programming. Single
exit rule however is clearly procedural programming idiom, since it
tells nothing about objects.

 

[Ian Collins]

A counterargument to multiple returns is that it renders the function
less amenable to refactoring and therefore is likely to become even
more unreadable over time as additional conditions need to be handled
etc.

I would argue the opposite. If a function is written with multiple
returns, it's less likely to have shared clean up code that would have
to be extracted along with a logical block of code.

The argument that equates throwing exceptions with return statements
is spurious IMO. Throwing an exception is blatantly not the same as
returning normally from a function and the possibility of an exception
being thrown at a particular line of code does not have the same
effect on the function's amenability to being refactored.

No, but exception safe code is also early return safe code. I don't
think people do equate throwing exceptions with return statements.

 

[Öö Tiib]

Lifetime management and encapsulation are orthogonal issues (the
lifetimes of objects need to be managed whether they are encapsulated or
not,) so RAII, as a concept of lifetime management, has nothing to do
with encapsulation; even if it did, encapsulation is the essence of
modular programming which came long before OOP.

With each resource acquisition some object is initialized. That way
the acquired resources are always encapsulated in objects. All
resources, like locks or file handles or dynamically allocated
objects. I am not sure why you say it is not encapsulation?

Most programming paradigms have some common concepts with other
paradigms. That is natural. Why it matters what was long before and
what was after?

As such, I stand by my position that the rule in question has nothing to
do with OOP.

The idiom is only used by programmers of some object-oriented
languages. C++, Ada and D. It has something to do with ways how OOP
concepts are supported by these languages.

 

[Juha Nieminen]

encapsulation is the essence of
modular programming which came long before OOP.

The first object-oriented programming language is considered to be
Simula, developed in 1967. (Simula 67 introduced objects, classes,
subclasses, virtual methods, coroutines, discrete event simulation,
and features garbage collection.)

Which non-OOP modular programming language are you thinking of, which
"came long before OOP"?

(Sure, lots of programming languages support some kind of modularity,
but usually "modular programming language" is defined to entail more
than eg. just having compilation units and variables/functions local to
them. Although if your definition of "modular programming" is that, then
you could argue that Fortran, which came in 1957, is significantly
earlier than Simula, at least in computer years.)

 

[Student]

Hello Everyone,

I'd like to know you professional opinion on following coding rule
freshly
imposed by my beloved employer:
"Thou shalt not have multiple returns from function"

Personally i hardly understand that one, apart from "readability"
argument
which i would hardly qualify as sufficent to impose such rule.
When i think about it i found the exact opposite true, that multiple
returns
improve readability

Best regards,
Mojmir

So your old-fashioned employer wants this:

int func(int par)
{
int rc = ERR;
if (par == OK)
{
//...
rc = RESULT;
}
return rc;
}


I prefer this (and I think you too):

int func(int par)
{
if (par != OK)
returnERR;
//...
return RESULT;
}

My motto is: return as quickly/early as possible.

Ask your dinosaur employer which one is more clear, intuitive, safe, fast, short, and better...

 

[osmium]

So your old-fashioned employer wants this:

int func(int par)
{
int rc = ERR;
if (par == OK)
{
//...
rc = RESULT;
}
return rc;
}


I prefer this (and I think you too):

int func(int par)
{
if (par != OK)
returnERR;
//...
return RESULT;
}

My motto is: return as quickly/early as possible.

Ask your dinosaur employer which one is more clear, intuitive, safe, fast,
short, and better...

Your employer has just told you which one is better. Please pay attention!

 

[Student]

Your employer has just told you which one is better. Please pay attention!

Bye bye boss! Wish you much luck, you will need it!

 

[Öö Tiib]

Most programming paradigms build on what came before and OO is no
exception. I think that some people tend to forget that we were
programming successfully long before OO existed, and that not all
programming concepts are OO concepts. By the comment that Student made,
I thought that he could use a reminder that OO is not the beginning and
end of programming.

We discuss C++. Yes, for example class-based is one style of OOP,
other style of OOP is the one that uses prototypes and clones of such
prototypes (like Javascript) and there may be even more styles.
However here we discuss C++ OOP so here we expect it to be class-
based.

C is procedural language that deals with low level resource management
explicitly uses single exit (structured programming) idiom to ease
that task. Some OOP languages may use closures or finalizers for
recycling non-memory resources by their OOP engine. With C++ most of
us expect RAII (OOP) idiom to be used to let destructors to deal with
releasing resources instead of explicit resource management of C. That
is most robust and simple way.

You may use single exit idiom as well in C++, since most C compiles
with C++ compiler. It lacks the effect since there are exceptions in C+
+ language that sort of break it. It also lacks the purpose if you
anyway have to bind the resources to objects with RAII idiom.

[...]

Looking at the responses to that comment, I'm beginning to wonder why
several others want to insist that a "single exit vs multiple exit"
discussion relates to the object-oriented paradigm.

Classification is of less interest for me, but i am still curious. To
what concept of what paradigm that RAII belongs then? I suggested
there above encapsulation and not module-level but object-level
encapsulation ... so C++ style OOP.

 

[James Kanze]

I would argue the opposite. If a function is written with multiple
returns, it's less likely to have shared clean up code that would have
to be extracted along with a logical block of code.

What does SESE have to do with clean-up code? SESE is used to
make it easier to reason about programming logic. If there's
only one return, for example, it's easier to verify that the
post-conditions are met. (All other things being equal, of
course. An overly complex function remains difficult to
analyse, single return or not.)

No, but exception safe code is also early return safe code. I don't
think people do equate throwing exceptions with return statements.

So why do they raise the argument here, with respect to single
returns? When you raise an exception, you are throwing in the
towel---you know that you can't meet the documented normal
post-conditions, so there's no point in continuing analysing
them.

 

[James Kanze]

FYI, OOP has no bearing on the rule in question whatsoever.

[/QUOTE]

It does if you consider RAII as part of C++'s OOP.

Except that RAII has nothing to do with OOP, or at least what is
classically understood with OOP (virtual functions, etc.). And
neither OOP nor RAII have anything to do with the rule banning
premature returns---it's more an issue of programming logic and
correctness.

 

[James Kanze]

On 05/12/2010 14:08, Daniel T. wrote:

[...]

RAII has everything to do with this rule as RAII makes old fashioned
SESE redundant.

How? SESE has nothing to do with managing resources: it's
a rule to simplify analysis of program logic, in order to ensure
program correctness.

RAII involves destructors and destructors are arguably
part of C++ OOP.

That's an original definition of OOP. In *every* definition
of OOP I've seen, polymorphism is an essential aspect. RAII
does not require polymorphism, and in most cases, makes no use
of polymorphism. (But of course, OOP has become such a wide
spread buzz word, it's hard to know what it really means.)

 

[peter koch]

For the third and final time Mr Troll:

SESE is commonly used to ensure any resources allocated in the function
are deallocated in one place; it is an easy mistake to omit freeing a
resource if a function has many returns; however, RAII ensures that
resources are freed irrespective of number of returns or if an exception
is thrown.  RAII makes SESE redundant and SEME common in modern C++
designs.

That is one purpose of SESE in some languages - not as we all know -
in C++. An other rationale is to make the function easier to read, and
that is the argument consistently forwarded by James Kanze and ignored
by you.

It is a bullshit position to say that constructors and destructors
(which RAII utilizes) has nothing to do with *C++* OOP.

They have nothing to do with James' advice and not much to do with OOP
as understood by most of us. Read any textbook on OOP, and RAII will
only pop up while discussing C++ (and Ada). Most OOP languages simply
don't have destructors.
And whenever words like "troll" and "bullshit" pop up in replies this
is a clear indication that the poster ran out of real arguments.


/Peter

 

[James Kanze]

On Dec 5, 10:16 pm, "Daniel T." <[email protected]> wrote:

[...]

We discuss C++. Yes, for example class-based is one style of OOP,
other style of OOP is the one that uses prototypes and clones of such
prototypes (like Javascript) and there may be even more styles.
However here we discuss C++ OOP so here we expect it to be class-
based.

Actually, at the start, we weren't discussing OO at all. While
there are many styles of writing OO (some particular to C++, but
most more generally applicable), an essential element of all is
polymorphism. That's what separates "object oriented" from
other paradigms.

C is procedural language that deals with low level resource management
explicitly uses single exit (structured programming) idiom to ease
that task.

C is a low-level procedural language, yes. How it deals with
low-level resource management is up to the programmer, however.
And the SESE structured programming idiom has very little to do
with it, having been developed for entirely different reasons.

Some OOP languages may use closures or finalizers for
recycling non-memory resources by their OOP engine.

Neither closures nor finalizers have anything to do with OO,
either. (Closures are typical of functional languages, for
example, and pre-date OO by several decades.)

With C++ most of us expect RAII (OOP) idiom to be used to let
destructors to deal with releasing resources instead of
explicit resource management of C. That is most robust and
simple way.

And? What does that have to do with the original question? Or
OO?

[...]

Classification is of less interest for me, but i am still curious. To
what concept of what paradigm that RAII belongs then?

As has already been mentionned, it's a form of encapsulation.
I don't think it's really associated with any particular higher
level paradigm, however: it really fits into many of them.
(I've seen similar concepts used in Lisp, for example.)

 

[James Kanze]

On 2010-11-23 10:04, mojmir wrote:

[...]

So your old-fashioned employer wants this:

int func(int par)
{
int rc = ERR;
if (par == OK)
{
//...
rc = RESULT;
}
return rc;
}

I probably wants significant names as well.

I prefer this (and I think you too):

int func(int par)
{
if (par != OK)
returnERR;
//...
return RESULT;
}

My motto is: return as quickly/early as possible.

That's fine if you don't care about program correctness.

 

[peter koch]

I (and others) totally disagree that SESE makes functions easier to
read; SESE can also make functions harder to read.  SESE/SEME has
nothing to do with program correctness except for the fact that
SEME+RAII can actually result in less bugs.





We are dicussing OOP in the context of C++; constructors and destructors
are part of C++ OOP.

Mr Kanze has a track record of troll like replies including "a function
should contain no more than 10 lines of code" for example.

I agree that one should strive for the single return statement. Most
often it makes the function easier to read. There are exceptions to
this, so I would not cast the rule in stone.
For the other rule I must also agree: most functions should not be
more than ten lines - at least not longer than you can look at it on a
normal window in your development environment.

/Peter

 

[Ian Collins]

What does SESE have to do with clean-up code?

Isn't that obvious? If a function only has one return, it's tempting to
perform clean up before the return. If a function is written to be
exception or SEME safe, resources allocated have to be automatically freed.

SESE is used to
make it easier to reason about programming logic. If there's
only one return, for example, it's easier to verify that the
post-conditions are met.

By inspection yes, by testing, no.

So why do they raise the argument here, with respect to single
returns?

Because exception safe code is also SEME safe code.

 

[Ian Collins]

No it isn't; Kanze has a point here, in SEME you have to fulfill function
post-conditions, in case of exception you don't. So exception safe code
is easier than SEME in this regard.

To a point, I agree. But in most of the SESE code I see (which is in C)
the clean up code is concerned with freeing resources. Whether
function post-conditions have to be fulfilled or not, throwing an
exception should not leak resources.

 

[Ian Collins]

That's fine if you don't care about program correctness.

That's an incredibly pompous and condescending comment James. You are
starting to come across like a religious extremest; your way is the one
true way and everyone else is a cowboy.

Do you really claim the programmer who writes

{
if( !precondition )
return error;

// do stuff
}

cares less about program correctness (or readability) than the
programmer who writes

{
if( precondition )
{
// do stuff
}
else
return error;
}

?