From: Robert Dober <robert.dober@...>
Date: 2006-12-30T17:34:08+09:00
Subject: Re: Methods validating their arguments: good or bad?

------=_Part_111015_24331018.1167467646037
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 12/29/06, Michael Judge <mjudge@surveycomplete.com> wrote:
I *was* quite radically for early checking and got lot`s of arguing, I pipe=
d
down than and
started thinking why something *so* obvious was not wildely recognized by
the community.
I had some ideas about it may I?

Code Complete* recommends that methods validate the arguments they
> receive.  The author went on to say that in a 1984 study,


That =B4s it 1984 I was still in university, there was C, Pascal, Algol,
Ada83, C++(just I guess), Lisp Fortran Cobol - there was Smalltalk too, but
who considered it in those times .
There was no TDD or BDD, there was no Extreme Programming, Testing was just
not part of development.
How much do such studies apply to modern agile languages which *should* use
a different developement approach?

researchers
> discovered that miscommunication between routines caused 39% of the
> programming errors observed.  The idea is that, if we check our
> arguments before using them, bad data won't flow through undetected,
> causing even vaguer problems later on.  Lucky for us, Ruby checks the
> number of arguments received against the method definition -- finding
> many of these problems at the time they're written.  But checking
> that the arguments make sense are still our responsibility.


It might be much tougher to do that than to say that.

  Should
> we do it?  Is it too much overhead for too little gain?
>
> From the Rails source:
>
> def select_tag(name, option_tags =3D nil, options =3D {})
>    content_tag :select, option_tags, { "name" =3D> name, "id" =3D>
> name }.update(options.stringify_keys)
> end
>
> The arguments to select tag are really easy to screw up.  Adding code
> to validate them would add four or five lines to this terse method.
> Plus it would probably need a few helper methods just to remain
> readable.  But it would also prevent programmers from wasting huge
> amounts of time hunting for why their browser rendered a bad select
> box.


This is a very good case of yours as we are talking about an exposed API,
and thus TDD cannot really apply as in a closed (project) API where tests
should catch a many errors.
Still I think it is not the early checking which is missing most but maybe
documentation?

The argument for adding validation is really strong for any non-
> trivial project, but does it ruin Ruby's elegance?


Yes I am afraid so, and furthermore the validation argument is something I
feel I carry as a burden from my Ada and Pascal past, and it is not as
important as I felt.

What do you think?  Do you usually validate your arguments?


Less and less, but the less I validate the more I develop in TDD (or BDD if
I am in a good mood).
OTH I would still tend to validate a lot if I were exposing an API, that
seems the crucial point to discuss to me.

- Michael Judge
>
> * Code Complete is a book on software construction by Steve McConnell.
>
>
Cheers
Robert

--=20
"The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. Don't be misled by the enormous flow of money into bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas."

- Alan Kay

------=_Part_111015_24331018.1167467646037--