Defensive Programming

Defensive Programming

1. Defensive design

   • Input validation
     • Checks input meets certain requirements
       • Still be errors
     • Presence check
       • Input is not blank
     • Format check
       • Input matches a certain pattern
         • ie. email contains @
         • ie. postcodes
     • Length check
       • Input is the right length
         • ie. Name not 30 characters long
     • Type check
       • Data is the right type
         • ie. string, integer
     • Range check
       • Input is in an acceptable range
         • ie. between 1 and 12
   • Input sanitisation
     • Data is cleaning of any unwanted characters
       • ie. Strip out spaces
   • Anticipating misue
     • People will try to abuse the program
   • Authentication
     • Passwords
       • Complex
       • Changed regularly
     • Access levels
       • Limits access to certain areas
     • Limited login atempts

2. Testing

   • Iterative
     • Ongoing testing that is done whilst the program is being developed
     • Aimed at removing bugs
   • Final
     • Testing that is done when the program is complete
     • Tested against the requirements of the customer
   • Test tables
     • Valid data
       • Should produce expected results
     • Invalid data
       • Should produce an error
     • Borderline data
       • Data that is inbetween valid and invalid data
         • ie. maximum 30 characters
           • check 30
           • check 31
   • Check for syntax, run-time and logic errors

3. Maintainability

   • Code can be understood by other developers
     • More robust as reduces risk of introducing new errors
     • Indentation
       • More structure and reads easier
     • Commenting
       • Makes clear what each section of code does

4. Make more robust = less errors

5. Protect against misuse