2.3 – Producing robust programs

input validation

checking data input by the user meets specific criteria/ rules before processing

5 input validation techniques

type check-was the data entered in the correct data type and the programmer can resolve this by working with inputs as strings rather than casting them to numbers

range check- was the input in the correct range

presence check-has mandatory?required data has been entered

format check- is the data in the correct format

length check-does the input have the correct(min/max) number of characters

by using input validation techniques a programmer can make their program:

-more robust

-more user friendly

-prevent further errors occuring later in the algorithm

anticipating misuse(planning for contingencies)-division by zero

-division by zero=in maths no number which when multiplied by 0 returns a non-zero number. therefore the ALU cannot compute a division by 0 and so a programmer should check that a variable is not zero before attempting a division

anticipating misuse(planning for contingencies)-communication error

online systems require connections to host servers. If this connection is dropped, unable to be established or the server is overloaded, it could potentially cause a program to crash or hand when loading/saving data

-a programmer should enable ways for the user to cancel requests or for them to fail gracefully, reporting the connection error

-the program may be able to automatically resume when the connection is available again

nticipating misuse(planning for contingencies)-printer and other peripheral errors

-if a program outputs a hardcopy, the printer may run out of paper, ink or have a jam

-the programmer should not assume that an output to a printer was successful and always have options to reprint reports and receipts

anticipating misuse(planning for contingencies)-disk errors

-programs that read and write to files need to handle many types of exceptions including:

-the file/folder not being found

-the disk being out of space

-the data in the file being corrupt

-the end of the file being reached

• robust programs will handle all these situations by checking files and data before attempting to use them for further processing

one way to ensure that the data used by systems is kept secure

authentication

• username and password to access systems

• recovering a password requiring clicking on a link within the email that is sent to be registered address

• encryption of data files

• online bots can submit data automatically to online forms

• this can be protected against software such as reCAPTCHA that verifies the user is human

• programmers should also be aware of the potential for SQL injection hacks and other methods used by hackers

how to write maintainable code

use comments to:

• explain the purpose of the program

• explain sections of code. Typically selections, iterations and procedures

• explain unusual approaches that were necessary

• visually divide sections of a program

• use white space to make sections of a program easier to see

• use indentation for every selection and iteration branch

• use descriptive variable names and explain their purpose with a comment when declared

• use procedures and/or functions to:
  -structure the code

  -eliminate duplicating code

• use constants declared at the top of a program

syntax error

the rules of the language have been broken

-the program will not run (compiled languages)

-syntax errors can happen because:

variables are not declared or initialised before use

incompatibility of variables types e.g total= “A” (total declared as an integer)
-using assignments incorrectly e.g 2+2=x

-keywords misspelt e.g prnt(“enter choice “)

logic error

the program runs but does not give expected output

logic errors can happen because:

-conditions and arithmetic operations are wrong

-sequences or commands is wrong

-division by zero

-exceptions e.g file not found

4 main reasons why a program should be tested include:

-to ensure there are no errors(bugs) in the code

-to check that the program has an acceptable performance and usability

-to ensure that unauthorised access is prevented

-to check the program meets the requirements

types of testing

-iterative testing:

-performed whilst the software is being developed

-each new module is tested as it is written

-program branches are checked for functionality

-checking new modules do not introduce new errors in existing code

-test to ensure the program handles erroneous data and exceptional situations

-final/terminal testing:

performed when the program is finished

-testing that all modules work together (integration testing)
-testing the program produces required results with normal, boundary, invalid and erroneous data

-checking the program meets the requirements with real data

-a beta test may find more errors

-worth noting that there will be some situations that havent been covered and so maintenance on the program is important

test data needs to include a range of:

erroneous data--data of the incorrect type which should be rejected by a computer system

and this includes no data-you should always check the special case of no data being entered r to do

invalid data- data of the correct type but outside acceptation validation limit

normal data-data which should be accepted by a program without causing errors

boundary data-data of the correct type which is on the edge of accepted validation limits

refining algorithms to make them more robust is about:

-writing code which anticipates a range of possible inputs

-those inputs could be invalid or erroneous data

-making sure that “bad” data doesn’t crash the program

-making sure prompts to the user are descriptive and helpful

-making sure only data of the correct “data type” are entered

-checking and handling missing or blank data

-one common option is to use simple exception handling commands available in most programming languages