What is Coding Standards in Software Engineering?
Representative coding standards:
1. Rules for limiting the use of globals: These rules list what types of data can be declared global and what cannot, to limit the data that needs to be defined with global scope.
2. Standard headers for different modules:
The header of different modules should have a standard format and information for ease of understanding and maintenance.
i. Name of the module.
ii. Date on which the module was created.
iii. Author’s name.
iv. Modification history.
v. Synopsis of the module. This is a small write-up about what the module does.
vi. Different functions supported in the module, along with their input/output parameters.
vii. Global variables accessed/modified by the module.
3. Naming conventions for global variables, local variables, and constant identifiers: A popular naming convention is that variables are named using mixed case lettering. Global variable names would
always start with a capital letter (e.g- GlobalData) and local variable names start with small letters (e.g- localData). Constant names should be formed using capital letters only.
4. Conventions regarding error return values and exception handling mechanisms: The way error conditions are reported by different functions in a program should be standard within an organisation.
Representative coding guidelines:
1. Do not use a coding style: Code should be easy to understand. Many inexperienced engineers take pride in writing cryptic and incomprehensible code. Clever coding can obscure the meaning of the code and reduce code understandability, thereby making maintenance and debugging difficult and expensive.
2. Avoid obscure side effects: The side effects of a function call include modifications to the parameters passed by reference, modification of global variables, and I/O operations. An obscure side effect is not obvious from a casual examination of the code. Obscure side effects make it difficult to understand a piece of code.
3. Do not use an identifier for multiple purposes: Programmers often use the same identifier to denote several temporary entities.
4. Code should be well-documented: As a rule of thumb, there should be at least one comment line on average for every three source lines of code.
5. Don’t use GOTO statements: Use of GOTO statements makes a program unstructured. This makes the program very difficult to understand, debug, and maintain.