Reasons to create routines

 Reduce complexity  Promote reuse

 Avoid duplication
 Anticipate change
 Hide sequences
 Hide data structures
 Improve performance
 Improve readability
 Improve portability
 Isolate complexity
 Multiple languages
 Simplify boolean tests

11/17/2018 (c) Ian Davis 1

 Size of a routine
 Routine size inversely correlated with error
 As size  to 200 lines errors per line  (Basili)
 Routine size not correlated with errors
 Structural complexity and amount of data far
more significant than routine size (Shen)
 Larger routines (65+ lines) cheaper and no
less reliable (Card)
 Small routines (<143lines) has 23% more
errors than larger routines.

11/17/2018 (c) Ian Davis 2

 Size of a routine
 Code in which all routines about 10 lines
long, as incomprehensible as code without
routines at all (Conte).
 Code required less change when routines
averaged 100 to 150 lines of code. (Lind).
 Practical upper limit on routine size about
200 lines of hard code (without comments).
 Most buggy routines had > 500 lines code.

11/17/2018 (c) Ian Davis 3

 Defensive programming tips
 Use lots of assertions.
 Avoid creating assertions with side-effects.
 Check correctness of inputs.
 Anticipate unexpected types in case
statements, etc.
 Document changes and use version control
 Monitor memory leakage.
 Employ firewalls between sections of code.
 Check for error returns.
11/17/2018 (c) Ian Davis 4
 Defensive programming tips
 Use macros to support / facilitate change.
 Nest macros using brackets.
 Order parameters as input, update, output.
 Use same parameter order for similar tasks.
 Compare with fprintf() and fputs()
 Use all parameters; optionally default some.
 Don’t use parameters as working variables.
 Hard to debug when viewing stack.

11/17/2018 (c) Ian Davis 5

 Defensive programming tips
 Prefix global and object state variables
 eg. m_pointer, g_counter
 Designate data private when appropriate.
 Distinguish pointers from non-pointers.
 Identify levels of indirection to arrive at an
element using a pointer.
 Use comments to explain what is clear as
well as what is unclear.

11/17/2018 (c) Ian Davis 6

 Comments for Routines
 For every routine, write a comment block that
includes:
 Functionality of the routine
 Every parameter: in or out, its meaning, restrictions,
assumptions
 Return value
 Errors or exceptions
 Explain complicated, tricky, or sensitive pieces
of code
 Write self-commenting code
 No excessive commenting
7
 Common Naming Problems - AVOID!!!
 Names that are misleading
 Names with similar meanings
 Names that are different by only one or two characters
 Names that sound similar
 Names that use numerals
 Names intentionally misspelled to make them shorter
 Names that are commonly misspelled in English
 Names that conflict with standard library-routine names
or with predefined variable names
 Names that are totally arbitrary
 Names that are hard-to-read characters (1 vs l O vs 0)

CS 3500 L13A - 8