Bad Programming 101: Part 2

2 min read

Error-Handling

  • Defensive Programming: Assume the input is problematic until prove otherwise
  • Assertions mayt be used as a debugging tool for the programmer (but never to say validate user input). Conventional wisdom is to use assert() to help debug your code, to warn you when something “impossible”, something that must not happen, has happened. This “warning” takes the form of exiting your program
  • Assertions are typically active only during development and testing
  • Checking an assetion shopuld not cause a change of state
  • Assume end-user is NOT a programmer and output error messages accordingly. Detailed error messages can be logged for retival by a maintainer later without confusing the end-user with them
  • Exceptions are recommended over error codes

Subroutines

  • Make subroutines small and easy to comprehend
  • Number of busy tend to increase with subroutine size
  • Do not use multipurpose subroutines (A function must do one thing only) but avoid excessive duplication though
  • Subroutine naming should be logical and sensibe to the reader
  • Cyclomatic Complexity: Counting the number of logical or decision pathways to get an idea about the complexity of the code
  • If the input parameters for the subroutine is growing long:
    • The subroutine is doing too much
    • Parameters should be unified to a new type
  • A lot of erros occur at the boundaries between subroutines, so check parameters before use
  • Checking parameters could include:
    • Check for NULL input
    • Mathematically valid input
    • Checking formatting of data as needed
    • Files are open or readable

Reusability of Code

  • The cohesion of a module can be:
    • Functional: Module performs a single task
    • Communicational: Tasks grouped which make use of the same data
    • Temporal: Tasks performed at the same time
    • Procedural: Module performs a bunch of tasks chained together to be performed in specific order
  • Modules should have minimum dependencies on other modules (i.e weak coupling)
    • Weak coupling examples: Passing messages or sharing parameters
    • Strong Coupling: Sharing data that gets multiple modules leading to gaps, overlaps etc.
  • Chapters on Classes, Class Design, Polymorphism and Inheritance to be revisited and updated later

Also see:

Bad Programming 101: Part 1

Graph View