Every individual developer who writes code has an obligation to ensure that the code satisfies the needs, that it was intended to serve. Other then the stated need, an implicit assumption is that it is robust enough. The Developer needs to review or test his piece, to ensure that.
So what should the developer check for?
Input validation
Any piece of code usually has some kind of an input, either through a UI, or as parameters for the function/ method or Data that is read from a file, db or some temp memory location.
is the value within the expected min/max limits, is it null, is it one of the expected values(in case of enum), is it numeric / alphanumeric / allowed special characters, is it the incoming data too big that it does not fit into the expected data type size limitations. Is it in valid format? (For example dates, regular expressions)
Valid Comparisons
Any comparison between two variables, x==y needs to checked if x & y are of compatible data types,
mode of comparison is also an important consideration, equals, less then, greater then, like, which is the appropriate one to use, based on the requirement or circumstances. has less then been used when less then or equal to is more appropriate, or is equals used, when like is more appropriate, ensuring that the condition being checked will return both true / false and is the correct set of statements under true / false or is it reversed. These are the kind of questions to ask oneself
Loops & Conditions
All kinds of loops and associated conditions such as select / case, while, for loop, will need to be looked at to check if, either the first element or last element may be left out, or the possibility of overshooting the no. of elements, problems due to the index (starting from 0 or 1), conditional checking such as < or <= which is the correct one? Proper use of break or continue to ensure that exit from loop happens, a default else or a default case, in case of a switch or a select case statements. another item not necessarily of the same category is recursive functions related problems, which need to be looked for.
Assignment - type mismatches
When the language being used allows implicit conversion among data types, there is a possibility of wrong assignments, a variable declared as a string might be assigned a number, date etc. but when reading from that variable and converting back, you will tend to get errors related to data type mismatch. when creating a variable of date/ time and assigning value from another input variable, then format, related issues may crop up especially when supporting I18N, 04/11/2008 may be interpreted as 11th April or 4th Nov, need to be watchful of such possibilities.
File and DB Access points
Another important area is proper closure of connections and freeing up of resources, in case a file is opened and read, has it been closed and the memory assigned been properly disposed. this applies on similar lines to Database connections also. Are the db objects such as record sets closed, if not, this may result in unwanted row level or table level locks. Resulting in a wait for ever, until the process is killed.
the same applies to files too.
Standards & Consistency
From a readability perspective the code can be checked for naming conventions, proper indenting, correct and relevant comments etc. well structured, preferably with an header indicating the purpose, and where this piece fits in the big picture.
Exception handling
In all of the above scenario's of failure conditions, having a mechanism to capture those exception cases, and logging that information for debugging purposes, and throwing a meaningful application defined error / exception message back, is important, during a review process we could check if all of the important areas where possibilities of exceptions are high, have the relevant mechanisms to catch them.. btw, this can be handled as a separate topic in some future discussions (possibly... not probably J )
I guess taking care of these, should make the code good enough, and ready for integration with other parts of the system.
No comments:
Post a Comment