Prefactoring

3.3. Validation

You should validate all input data before transferring it to internal processing. Violation of this rule has caused numerous web sites to be subject to attacks such as Structured Query Language (SQL) injection.^[*]

^[*] SQL injection involves using the entry fields on a web form to submit SQL commands to a database that is the backend for a web server. For more details, go to http://www.nextgenss.com/papers/advanced_sql_injection.pdf or search Google.

You should convert input to its corresponding abstract data type as it comes into the system. For example, you should convert an input field that represents a dollar amount into a variable of type Dollar. Failures of conversion (such as an amount that has three decimal digits) can be reported back to the user immediately. There is no sense in processing an invalid Dollar.

All identifiers should contain self-validating values that can prevent most common entry errors. For example, if a PhysicalID was used to identify each CDDisc, it should contain a check-digit or other error-detection mechanism. Common typing errors can be caught at input, instead of being passed along as erroneous data.^[*]

^[*] It is ironic (or perhaps a rhyming term) that one of the most widely used identifiers, the Social Security number, has no check digit.

The most stringent rule is that the value of every parameter to every method should be subject to validation . The rule can be relaxed if the caller of the method (or its caller) has performed ...