Prev: Inputs left floating at the very start
Next: Microcontroller USB interface chip
From: Andrew Smallshaw on 4 May 2008 10:49
On 2008-05-02, Robert Adsett <sub2(a)aeolusdevelopment.com> wrote:
>
> Changing a 2 to a 1 and a 1 to a two obviously ;) I have noted though
> that besides trying for the most obscure code to prove their worthiness
> to program no-one has actually verfied the inputs are in range.

<rant>

And? I don't know about everyone else but I find the constant
checking of prerequisites an annoying distraction when working on
code and a waste of time and space in final production code. I
can understand some extra sanity checking in debug code but these
should be in moderation and preferably protected by #ifdef DEBUG
or whatever.

If function f(x) is defined over the domain x = {1,2} and is
documented as such then there is no reason for f to check that the
parameter is a member of this domain. It is the responsibility of
the caller to ensure that this is the case and f is entitled to
return whatever it likes (or indeed not return) if this is not so.
Of course, for debugging it is useful to know straight away if x
is something different so a debug test may be appropriate but it
should be precisely that - a debug test and not in final code.

I have seen too many times code where the caller does a series of
sanity checks before calling the function which then repeats those
same checks. Does that strike you as remotely sensible? That
isn't smart or intelligent design - it actually indicates a poor
design process because you haven't made a decision as to where the
tests should be - in essence the function interface is poorly
documented regardless of any statement that may have been made
about the input domain.

Why place the burden on the caller? Well to begin with what if the
function returns a basic type - how do you indicate the error
condition in general? Also the caller has a much better understanding
of the circumstances in which the fucntion is being called. It is
often possible to reason that the caller simply cannot pass an
invalid value to the callee simply by the way it works.

I am not diminishing the importance of testing _external_ inputs
here - that is indeed necessary. But constantly checking the
results of other elements with your own program is a complete waste
of time. It doesn't matter how far you go, ultimately you have to
trust that the rest of your program works as intended.

</rant>

--
Andrew Smallshaw
andrews(a)sdf.lonestar.org
From: Robert Adsett on 6 May 2008 20:00
In article <fvqipm$c9k$1(a)aioe.org>, Andrey Tarasevich says...
> Robert Adsett wrote:
> > However, the fact that no one considered that the inputs could be out of
> > range (and for that matter your reaction to the observation) is an
> > interesting commentary on how we view this practice we call programming.
> > We seem to default to the assumption that the input values to our
> > current problem will be in the range we expect.
>
> Absolutely not. The correct view of the situation is that the notion of
> "verifying the input" is not generally applicable to and abstract
> interview-level problem, aside from the questions specifically crafted
> for the purpose of testing the subject's ability to perform the
> verification.

Well, we really had moved away from interview questions. Even then
though it would be instructive to see which candidates noted the range
limitations of their approach. I was more struck not that some disn't
note the limitation but so few did and no-one actually checked the input
for validity or added a comment that the output was only valid over a
certain input range.


> The same logic applies in this case. A solution that depends on the
> input to be in range is a B-grade solution. A solution that does not
> depends on the input to be in range, but still verifies it is a C-grade
> solution. An A-grade solution would behave correctly on the specified
> input, but also do something similar (and theoretically "useful") on the
> other inputs (meaning that there no need to verify the input). This is
> actually the main reason why the 'x = 3 - x' is the best solution of all
> presented. It is readable and at the same time it is based on the
> cleverly noticed elegant mathematical generalization.

While it is 'cute' and a clever trick, I wouldn't call it either the
best solution or an elegant mathematical generalization or even
particulary readable(1). If it showed up in a code review I'd send it
back to be re-written in a more obvious form unless there was a really
compelling reason to use it. Even then I would expect copious comments
as to why such an obscure form was being used.

> Adding an input
> check would make it as ugly as the 'if'-based solution. No, the input
> check is the responsibility of the caller in this case.

And a note to that effect eouldn't be appropriate? It's that there
appeared to be little appreciation for the restrictions of the
approaches I was finding interesting. And I'm not sure I would have
noted them myself if I suggested an approach which I also find
interesting.

Robert

1 - it did make a decent punch line,
** Posted from http://www.teranews.com **
From: CBFalconer on 4 May 2008 13:26
Robert Adsett wrote:
>
.... snip ...
>
> However, the fact that no one considered that the inputs could be
> out of range (and for that matter your reaction to the observation)
> is an interesting commentary on how we view this practice we call
> programming. We seem to default to the assumption that the input
> values to our current problem will be in the range we expect.

So you didn't bother reading my reply?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

** Posted from http://www.teranews.com **
From: Robert Adsett on 4 May 2008 13:07
In article <slrng1rj7g.c0f.andrews(a)sdf.lonestar.org>, Andrew Smallshaw
says...
> On 2008-05-02, Robert Adsett <sub2(a)aeolusdevelopment.com> wrote:
> >
> > Changing a 2 to a 1 and a 1 to a two obviously ;) I have noted though
> > that besides trying for the most obscure code to prove their worthiness
> > to program no-one has actually verfied the inputs are in range.
>
> <rant>
>
> And? I don't know about everyone else but I find the constant
> checking of prerequisites an annoying distraction when working on
> code and a waste of time and space in final production code. I
> can understand some extra sanity checking in debug code but these
> should be in moderation and preferably protected by #ifdef DEBUG
> or whatever.

I don't think we are tremendously far apart really. I just observed
that no-one considered the possibility that the numbers might not be in
range. No asserts, no comments about acceptable range, nothing. That
combined with the search for obscure techniques I find a telling
cultural observation.

We could go on about the details of when and how to error check and I'm
not a paragon of checking either.

However, the fact that no one considered that the inputs could be out of
range (and for that matter your reaction to the observation) is an
interesting commentary on how we view this practice we call programming.
We seem to default to the assumption that the input values to our
current problem will be in the range we expect.

I wouldn't be surprised if obscure coding techniques and insufficient
range checking go together. And to be fair I think most contributions
to the obscure examples have been tongue in cheek.

Robert
** Posted from http://www.teranews.com **
From: Dombo on 4 May 2008 13:48
Andrew Smallshaw schreef:
> On 2008-05-02, Robert Adsett <sub2(a)aeolusdevelopment.com> wrote:
>> Changing a 2 to a 1 and a 1 to a two obviously ;) I have noted though
>> that besides trying for the most obscure code to prove their worthiness
>> to program no-one has actually verfied the inputs are in range.
>
> <rant>
>
> And? I don't know about everyone else but I find the constant
> checking of prerequisites an annoying distraction when working on
> code and a waste of time and space in final production code. I
> can understand some extra sanity checking in debug code but these
> should be in moderation and preferably protected by #ifdef DEBUG
> or whatever.

The assert() macro (or a homebrew equivalent)) offers a reasonably
concise way to achieve that, and can be considered to be a way of
documenting the pre- and postconditions of the code.

My experience is that a bit of defensive programming saves far more time
than it costs. Not only because catching errors early can save days of
debugging and (re-)testing, but more importantly because it forces one
to think about the pre- and postconditions and make them explicit.
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Inputs left floating at the very start
Next: Microcontroller USB interface chip