Re: Had an interview

On 2008-05-02, Robert Adsett <sub2@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Young person gave me a good idea
    ... I ask for the reason I should deal with a>>>company ... I treat it as a game - if I can get the caller to ... somebody trying to sell me something, though, ... These robo-dialers can't read no call lists or anything else. ...
    (soc.retirement)
  • Re: Ensuring that a thread doesnt own a critical section within a function
    ... I need to ensure that the thread calling fdoes not own critical ... that the caller's reason remains valid. ... The caller will assume ... timeout is not an option because fmust ensure the second thread is ...
    (comp.programming.threads)
  • Re: Authentication failures
    ... Reason: Unknown user name or bad password ... Logon Failure: ... Caller User Name: - ...
    (microsoft.public.windows.server.sbs)
  • Re: malloc()/realloc() - have I got this right?
    ... For some reason that is beound me you elected to ignore CBF's next ... The debate was whether the caller or the callee should disambiguate ... small amount of otherwise extra work in the calling code, ... or go home and simply say "the salmon was unavailable" and leave it to ...
    (comp.lang.c)
  • Re: [OT] simple malloc() problem
    ... >> religion taken as fact. ... Once you understand that parameters are locals initialised by the caller, ... reason, declare them as const. ... Dan Pop ...
    (comp.lang.c)