attack of silly coding standard?

[mojmir]

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

 

[Ian Collins]

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"

Said employer must be a C programmer!

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

It's a good rule in C, where there isn't any automatic destruction.
Multiple returns are no different for throwing exceptions (I suppose
they ban those as well?)

 

[gwowen]

Personally i hardly understand that one, apart from "readability" argument which i would hardly qualify as sufficent to impose such rule.

It's not about readability, it's about only having to put clean-up
code in one place -- and sometimes it's about artificially decreasing
some complexity metric.

Any piece of multiple-return code can be refactored to single-return
by replacing "return foo;" with "retval = foo; goto return_statement;"
where the explicit goto is sometimes diguised as a break or a load of
nested if-else clauses.

IMHO: The complexity metric comes done, clarity rarely increases.

 

[Michael Doubez]

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"

SESE vs. SEME is an old argument.

Personally i hardly understand that one, apart from "readability"
argument
which i would hardly qualify as sufficent to impose such rule.

Well, it is part of Dijkstra's rules of structured programming which
merits attention.

But we could consider RAII as a way to have a SingleExit state which
is sufficient.

When i think about it i found the exact opposite true, that multiple
returns improve readability

It depends: a loop full of break and continue is not that much
readable. IMHO consistency in the usage of flow of control statements
is what improve readability.

 

[Juha Nieminen]

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"

That's one of the principles of the so-called structured programming
paradigm. It's a good rule of thumb in imperative languages such as C,
but it's less necessary in a RAII-based language like C++ (or a
garbage-collected language like C# or Java, although the lack of RAII
can sometimes cause awkward situations, especially in the latter).

There's one easy counter-argument to that principle when talking
about C++: In most cases you *can't* control if a function will be
prematurely exited or not. Why? Because any line of code might throw,
causing the function to be exited right there. (Ok, strictly speaking
you could surround every single function implementation with a
try/catch block, but that would be prohibitive and useless.)

From a readability point of view, some code can actually become
more complicated and less readable if you try to force one single
exit point, so the whole principle can actually be counterproductive.

 

[Jorgen Grahn]

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"

I don't like it and I find it decreases readability of those functions
which already have problems ... but if that's the worst rule your
employer has, you're a pretty lucky guy.

/Jorgen

 

[AnonMail2005]

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

Does throwing an exception count as a return?
If so, then the rule is seriously flawed.
If not, then I don't see it as too onerous.

HTH

 

[Puppet_Sock]

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

The one-return rule is part of a pattern of programming
methods. If you are not doing the other parts of the
pattern then it probably is not going to make a lot of
sense to try to follow just this one rule out of the
pattern. It is mentioned else-thread about structured
programming.

As another consideration: The usual rule about making
a function readable, comprehendable, testable, etc.,
is that a function should have a single well defined
purpose. So, if a function does have a single purpose,
then when that purpose is done, it's time to exit.
If the function can finish in many different ways and
at many different locations, maybe that's a sign that
the function really has more than one purpose.

Usually, I try not to have more than one return statement
in a function with the exception of error checking. If a
function parses its inputs and finds them maculate, then
I have it bail right away. I don't try to do a lot of
big if-brackets on the error checking. You know, if the
args all satisfy their range check, then do the job of
the function, else return an error value.
Socks

 

[Matthias Meixner]

Am 23.11.2010 10:04, schrieb mojmir:

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"

Trying to enforce readable code by the use of coding standard is flawed.
In your example you could use goto to jump to the single return
statement. Or you could use exceptions within the function to jump to
the single return. Or for the more adventuresome you might even try to
use setjmp/longjmp (and break RAII). As soon as coding standards do not
help you writing good code and users start to circumvent them the worst
things may happen (as in the setjmp/longjmp case).

 

[Stuart Golodetz]

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

My opinion is that you're working for a micro-manager (the phrase
'beloved employer' suggests to me that there may be a trend going on
here) It's a poor leadership style because (a) it's impossible for
anyone to control every single aspect of a large project, and (b) it
demoralises your team, because it implies that you don't trust them to
do their job. A better approach is to hire people you can trust, and
then manage them with a light touch

Unfortunately, the sort of person who micro-manages generally does so
because they like to try and control everything -- so standing up to
them when they hand down rules from above tends to lead to sparks flying
(and you generally end up fighting a battle from a position of
weakness). Best advice I can give -- only fight battles with them when
it affects the quality of the end result. If they micro-manage you too
much, you might ultimately need to move on and find a better place to work.

The key thing is that if you ever end up in a position of leadership
yourself, you should remember what it was like to be micro-managed --
and not inflict it on other people. You shouldn't be too laissez-faire,
as that causes other problems, but you do need to know when to let
people get on with it without interference from above.

For what it's worth
Stu

 

[Juha Nieminen]

But, I think it's worth mentioning that it may not be the wisest course
of action to present a compelling counter-argument to one's boss. Some
bosses may consider it a threat to their authority, or resent having a
subordinate see the folly of a poorly-chosen policy. Such bosses may,
if one is lucky, simply dig in their heels and stubbornly insist on the
policy anyway. If one *isn't* so lucky, one can find one's self labeled
as "not being a team player," or even as being "insubordinate."

Would you want to work for such a boss?

 

[osmium]

Am 23.11.2010 10:04, schrieb mojmir:

Trying to enforce readable code by the use of coding standard is
flawed. In your example you could use goto to jump to the single
return statement.

I think the rule is misguided. The premature return offrered by break is
one of the big advantages of C over Standard Pascal.

I also think that anyone who applied such a workaround, after having the
merits of the rule explained to him, should be fired. This is simple
intransigence.

 

[Magno]

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

Who knows, knows... Who doesn’t becomes boss.
Any questions?

 

[Magno]

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

Who knows, knows. Who doesn’t... becomes boss.
Any questions?

 

[Matthias Meixner]

Am 23.11.2010 21:18, schrieb osmium:

I think the rule is misguided. The premature return offrered by break is
one of the big advantages of C over Standard Pascal.

break does not always work: You cannot break out of multiple loops and
you cannot break out of a switch + loop. So this is not a substitute for
a premature return. A goto is, but this is also forbidden by some silly
coding standards.


Example:

int foo( int x)
{
switch(x) {
case 1: return 0;
// some other code here
}

// some other code here

return 1;
}

 

[Matthias Meixner]

Am 23.11.2010 19:24, schrieb Puppet_Sock:

Usually, I try not to have more than one return statement
in a function with the exception of error checking. If a

Since error checking is an important part, most functions will have more
than one return statement....

 

[Ian Collins]

In theory it shouldn't matter either way, but I personally find that in
practice it is far easier to test if there is only one return to deal
with.

Why? Tests test what gets returned, not how it gets returned.

 

[Stuart Golodetz]

Why? Tests test what gets returned, not how it gets returned.

Not all testing is black box testing.

 

[Ian Collins]

Not all testing is black box testing.

How do you test inside a function? Boxes come in all shapes and sizes.

 

[Miles Bader]

It's easier to place a single breakpoint than half-a-dozen breakpoints.
I've been down this road on this group before. I'm not dogmatic about
it, but I find that I practice single-exit more than most people, sorry
if you take exception to such a thing.

I think the real issue here is not really the rule per-se (it seems
reasonable enough, when treated as a guideline), but inflexible and
dogmatic application of coding standards.

Sadly, counter-productive control-freakery is not uncommon in this
industry...

-Miles