Re: attack of silly coding standard?
On Dec 6, 7:07 pm, Ian Collins <ian-n...@hotmail.com> wrote:
On 12/ 7/10 05:27 AM, James Kanze wrote:
On Dec 5, 8:32 am, Ian Collins<ian-n...@hotmail.com> wrote:
On 12/ 4/10 10:51 AM, Bob wrote:
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.
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.
Or freed at both return points. Or all of the return points
except one are before any resources are allocated. Or (by far
the most frequence case in my current work) the only "resources"
used are on stack variables.
SESE is sufficient to ensure that all resources are freed, but
it's hardly necessary. It is necessary for most of the more
mechanical means of reasoning about program correction, and it
does make reasoning about it simpler.
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.
Ideally, you need both. Testing can never prove that code is
correct, only that it is incorrect. And a lot of things simply
aren't testable. But a human can overlook things as well, so
testing serves as a guardrail.
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.
So why do they raise the argument here, with respect to single
returns?
Because exception safe code is also SEME safe code.
That's the first time I've heard the expression "SEME safe
code". We speak of exception safety because exceptions
introduce invisible edges in the flow graph; we also only use
exceptions in cases where we've abandonned trying to achieve
a significant part of the normal post-conditions. Neither is
necessarily true with SEME.
I think I understand what you're trying to say, but I think your
confounding two separate issues.
--
James Kanze