High-Quality Routines ------------------------------------------------------------------------ Big Picture Issues * Is the reason for creating the routine sufficient? * Have all parts of the routine that would benefit from being put into routines of their own been put into routines of their own? * Is the name a strong, clear verb-object name for a procedure or an object name for a function? * Does the name describe everything the routine does? * Does it have strong cohesion—doing one and only one thing extremely well? * Does it have loose coupling—is the connection to other routines small, intimate, visible, and flexible? * Is the length of the routine determined naturally by its function and logic, rather than artificially by a coding standard? Defensive Programming * Are assertions used to document assumptions? * Does the routine protect itself from bad input data? * Does the routine handle bad data gracefully? * Is the routine designed to handle changes gracefully? * Have debugging aids been installed in a way that they can be activated or deactivated without a great deal of fuss? * Have errors been firewalled so they don't affect code outside the routine? * Does the routine check function return values? * Is the defensive code that's left in production code designed to help the user rather than the programmer? Parameter Passing * Do the formal and actual parameters match? * Are the routine's parameters in a sensible order, including matching the order of similar routines? * Are interface assumptions documented? * Does the routine have seven or fewer parameters? * Are only the parts of structured variables that are needed passed to the routine, rather than the whole variable? * Is each input parameter used? * Is each output parameter used? * If the routine is a function, does it return a value under all possible circumstances? ------------------------------------------------------------------------ Copyright © 1996-1998 Construx Software Builders, Inc.