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?