click below
click below
Normal Size Small Size show me how
J277 2.3.1
Defensive Design
| Term | Definition |
|---|---|
| Comments | Useful for explaining what the key features of a program are and to help programmers understand what to do |
| Indentation | Used to separate different statements in a program. For example, the code within a loop, or a selection statement |
| Input sanitisation | Removing any unwanted characters before data through the program |
| Input validation | Checking if data meets certain criteria before passing it into the program |
| Whitelist | A list of all data that a program should accept– any data that isn't on the whitelist will be rejected |
| Blacklist | A list of the data that a program should reject – any data that isn't on the blacklist will be accepted |
| Defensive design | Helps to ensure programs function properly with clever design |
| Authentication | Can confirm the identity of a user before they're allowed to access certain pieces of data or features of the program. |
| Maintainability | Making code easily to read and follow e.g. using comments, indentation and sensible variable names |
| Anticipating misuse | Identifying and preparing for potential incorrect or unintended usage of a program e.g. false inputs |
| Naming conventions | Agreed guidelines for naming variables and functions |
| Sensible Variable names | A method of maintainability where you use variable names that are easy to understand |
| Range check | Checking to see if an input is within a certain range |
| Length check | Checking to see if an input is a required length |
| Presence Check | Checking to see if something is present i.e. an input is filled in |
| Format check | Checking the format of an input e.g. a postcode or date of birth |