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?