"Patient Guy" <sevisen.adam@gmailDOTHEREcomwrote in message
news:Xn******************@207.115.17.102...
>
Does anyone have any coding rules they follow when doing argument
checking?
I've some general guidelines that I follow.
Firtly I would define "arugment checking" as dedicated code to determine the
existence of an argument and optionally it's type, format or content and
react according to need. The reaction might be to default the value of the
argument, throw an error or just plain ignore it.
Generally I WILL perform argument checking when:
+) The code in question is a "black box" of functionality. Components and
libraries designed to be imported and used by others should, I believe,
assume no special or deep knowledge of the code's inner workings. Argument
existence and type checking should be done and appropriate (and clear) error
messages provided.
In general the more any piece of code (function, method, custom object, etc)
is aimed at re-use the more formal I'll get about argument checking.
+) The code in question accepts end-user-generated ("uncontrolled") input.
When the code in question can accept uncontrolled input (as from a form
field perhaps) you should make it a point to check the argument. Almost all
field validation can be seen as a kind of "argument checking" (or maybe more
accurately "parameter checking").
Never trust a user.
+) When data-typing is required. Does your method require a number? An
array? A date? If so it's a good idea to check the input to make sure
you're getting what you know you need.
+) When the arugment is optional (especially when it's optional and can be
set to a default). Arguments are often optional, argument checking will
tell you if these optional arguments have been passed or not so that your
code can react appropriately. In many cases you may want to default the
value of these optional parameters (for example an optional string might
better be set to a blank space rather than left as undefined).
+) Whenever failure to check the argument can cause things to go belly up.
This is pretty simple but why let your code get (possibly) deep into a
(possibly time-consuming) process only to discover that an argument is
wrong/missing/hosed in some way? Better to check up front an react quickly
in my opinion.
I will generally NOT perform argument checking when:
+) The code is "automated" and called only by formalized code. For example
I prefer in some cases to provide generic eventhandlers: onChange and
onFocus and so forth that take a form field as an arugment. Since these are
called only by form field-specific event handlers in the form of
"onChange(this)" there really isn't much of a need to check the argument.
+) When the code is so simple that any error will both be quickly encoutered
and just as illuminating as any custom one provided.
Most of the time however I'll lean towards full, formalized argument
checking.
When arguments fail during check, do you return from the call with an
ambiguous return value, or do you throw exceptions?
It depends. As a general rule it's a good idea in most cases. For me I
look at the method/function as a series of questions and resulting
statements (flow chart style). This is why it's best to define (write a
specification) for your code beforehand: the answers will be in there.
For example consider a function "parseDate(Input)". The function takes a
value and tries to convert it to a date - if it can, it returns the date, if
not it returns null. Your specification has the answer: anything that can't
be converted to a date results in null.
Considering that I would check the input argument and if it's not a string
return null immediately. You _could_ return an error that says "a string is
required" but that adds unneccessarily to the definition.
In this case the usage is easier as well. You don't have to wrap
parseDate() in try/catch blocks every time you use it.
On the other hand sometimes an error is needed. Consider a function
countVowels(Input) which takes a value and returns the number of vowels in
it.
Here the spec doesn't define an "out" - you have to return a number. Since
asking for the number of vowels in, say, an integer value, is nonsensical
(returning "zero" this case would be misleading, I think) I would throw an
error for all non-string input. You'll either get an error or a number.
All told its best to find a style and stick to it even if it's sometimes
counter intuitive. Consistency helps you more in later maintenance more
than almost anything else.
Jim Davis
