CODE bad inputs Not just the error messages,

CODE
REVIEW

The point
of the code review is to check the code that has been developed for a system
for faults, strengths and weaknesses. This helps to develop ways to optimize
the code for better performance and helps improve documentation for higher code
quality. This delivers an error-free/ bug -free application that meets the requirements
of the customer/ end -user. The following points describes the standard that
code should be designed and should be used as a checklist for any functionality
that has been added.

1.      
Code
Objective

The code for functionality X achieves
its purpose for what it’s designed for. It should follow the following the
objectives below to ensure correct architecture and should follow the set code
standard and quality. See code standard and quality.

2.      
Code doesn’t
break

Validations are used wherever
necessary. The code never breaks under any circumstances. Especially under
invalid inputs that come from the end user. Examples of the inputs could
be that they’re negative, over-sized or have an invalid format etc. Every input
passed should be sanitized before its processed, to prevent code breaking.
Every object is checked for its actual data existence before accessing its
properties.

3.      
Architecture
is constant throughout

Check that the approved
architecture/design is followed throughout the application. If there are any
design changes required, make sure that these designs are documented, tested
and approved before implementing them in the existing code.

4.      
Error responses
for bad inputs

Not just the error messages, every
response that is returned by the server must be properly handled. It should
have response messages, error codes and any other necessary details attached so
responses are as useful as possible to the end – user. The format of these responses
should be as consistent as possible. All possible scenarios are tested to avoid
deadlocks, timeouts, etc.

5.      
Tested

Every core method has a unit test
which passes.

6.      
Reusable/No
repetition

All methods serve a limited and clear
purpose follows the methodology of the DRY principle. Functions are reused wherever
possible.  Any implementation of these
functions should be written in such a way that they can be re-used in the
future implementations. There is no duplication of code.

7.      
Code has
adequate/good performance

Code performance is good. There are
no significant delays between the requests and responses. The code is scalable
and able to handle a large amount of data and any upcoming features of added
new functionalities.

8.       Code is secure

The code is secure in terms of
authentications (with encryption), injections, unauthorized access, directory
browsing, SQL injection, cross-side scripting, etc.