On 12/29/06, Michael Judge <mjudge / surveycomplete.com> wrote:
>
> Code Complete* recommends that methods validate the arguments they
> receive.  The author went on to say that in a 1984 study, 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.  Should
> we do it?  Is it too much overhead for too little gain?
>
>  From the Rails source:
>
> def select_tag(name, option_tags = nil, options = {})
>    content_tag :select, option_tags, { "name" => name, "id" =>
> 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.  The argument for adding validation is really strong for any non-
> trivial project, but does it ruin Ruby's elegance?
>
> What do you think?  Do you usually validate your arguments?
>
> - Michael Judge
>
> * Code Complete is a book on software construction by Steve McConnell.
>
>

It depends.

Public APIs used by many clients, or even by the world via a service?
I would say at least consider validation.  There are a bunch of good
examples of how to do it declaratively and cleanly in the Ruby
Cookbook, and of course in the archives.

Internal apis, protected and private methods?  Eh, not so much.

Unless that internal api has some crazy parameter list it expects that
we'll be tough to figure out via just the code and tests.  In that
case, it again may be worth it.  Of course, that kind of thing is a
code smell in of itself...but sometimes its easier to raise an
exception with a decent error message then refactor crufty code.

- Rob