What is a 'robust' program?

A robust program is one that has been well planned and coded to take account of all possible issues that it may face. It should cope with the user taking any action at all, and should not crash or expose a security issue.

Programmers need to consider all possible issues that may cause problems, including a malicious attack from someone trying to break the system.

Planning for contingencies

There are many ways that a user can accidentally, or deliberately try to break a program. One accidental action is when a user tries to input the same data twice. A good example is when someone tries to use Twitter, which allows you to send the same tweet only once. If you send the same Tweet twice the program identifies this and removes the tweet, sending you an error message.

Once a programmer has anticipated the misuse they can then plan for the these issues, for example:

• Limiting the number of logon attempts
• Ensuring the code is robust in validating the data entered.

Authentication

Another method used is authentication. Authentication is a coding method to check that a user is who they say they are and allowed to accesses the program. This can be as simple as the user entering a user name and password which is compared against a stored user name and password. If they match then the user is authenticated.

There are also physical ways of authenticating input:

• New software often requires a key code which is generated by an app on the users phone and then entered.
• Online banking requires a user to enter credentials into a webpage and then a number is generated which is entered into a key device.
• This returns a number code which is entered into the webpage as well.
• Without the second part of the code the user is not authenticated.

Authentication methods can vary from passwords to patterns and even image scanners. Authentication also occurs when you access a website, you request access to the server which hosts the page.

A summary of basic web authentication goes like this:

• You make for a request for a webpage by typing in the URL
• The server responds with an error, requesting authentication
• Your device retries request - with authentication details encoded in request
• Again the server checks the details and sends the page requested, or another error

When a programmer includes comments in their program, they make it much easier for future programmers to understand what the program does.

# comments can explain what each section of code actually does

# comments can point out certain requirements of each section of code

# comments can describe and explain any issues with the code, which may be resolved at a later date

The comments will be read when anyone wants to gain an understanding of how the code works, which will save a lot of time in the future when the code might need to be altered, or a bug needs to be identified and removed.

Another useful tool to make code easier to read and maintain is how the actual code is laid out. Many programming languages insist on using precise indents, and they identify blocks of code that carry out a connected function. You can also use comments like this:

##########################################################

# This is an instruction explaining what this code does  #

# it will really stand out!                              #

##########################################################

Whenever a new program is developed, it should be thoroughly tested to see that it works as expected and without issue. This will identify any faults, which may be logical design faults, or syntax errors, which are mistakes in the layout of the code.

Developmental testing, also known as iterative testing should be done as the program is written. Whenever a block of code is completed, the code should be tried out, which may involve altering some parts of the program or adding extra lines to overcome errors which would not occur when the whole program has been written.

Final or terminal testing is carried out when the initial coding is finished and the program is "complete". A formal set of tests, designed to test every aspect of the programs function, should be designed and used to stress-test the solution. Whenever a user is required to input a value, a suitable set of test data should be created, and expected results should be predicted. The test data will include:

• Normal data - this is data that the program should expect and deal with normally.
• Extreme data - if a value that is required falls between two limits, then the program should be tested with data that lies at the very extremes of those limits. The program should deal with it in the same way as normal data, although it may sometimes trigger a warning message to alert the user that it is at the extreme.
• Erroneous data - This is data that should be rejected because it is wrong. It may include typing a word instead of a number, or data that lies outside of an acceptable range. It could also include symbols that may cause the computer an issue, or SQL commands which the program should sanitize and block.