Coding and Documentation Criteria
Back-end coding criteria
•
Standard headers for different modules:
For better understanding and maintenance of the code, the header of different modules
should follow some standard format and information. The header format must contain
below things that is being used in various companies:
o Name of the module
o Date of module creation
o Author of the module
o Modification history
o Synopsis of the module about what the module does
o Different functions supported in the module along with their input output
parameters
o Global variables accessed or modified by the module
•
Naming conventions for local variables, global variables, constants and functions:
Some of the naming conventions are given below:
o Meaningful and understandable variables name helps anyone to understand the
reason of using it.
o Local variables should be named using camel case lettering starting with small
letter (e.g. localData) whereas Global variables names should start with a capital
letter (e.g. GlobalData). Constant names should be formed using capital letters
only (e.g. CONSDATA).
o It is better to avoid the use of digits in variable names.
o The names of the function should be written in camel case starting with small
letters.
o The name of the function must describe the reason of using the function clearly
and briefly.
o Variables & methods’ names should be searchable (someone expects its name)
•
Indentation:
Proper indentation is very important to increase the readability of the code. For making
the code readable, programmers should use White spaces properly. Some of the spacing
conventions are given below:
o There must be a space after giving a comma between two function arguments.
o Each nested block should be properly indented and spaced.
CODING AND DOCUMENTATION CRITERIA
1
o Proper Indentation should be there at the beginning and at the end of each block
in the program.
o All braces should start from a new line and the code following the end of braces
also start from a new line.
•
•
Error return values and exception handling conventions:
All functions that encountering an error condition should either return a 0 or 1 for
simplifying the debugging.
There is always an Error Handling in conjunction with using Logger service to follow up
API processing.
o On the other hand, coding guidelines give some general suggestions regarding
the coding style that to be followed for the betterment of understandability and
readability of the code. Some of the coding guidelines are given below :
•
Avoid using a coding style that is too difficult to understand:
Code should be easily understandable. The complex code makes maintenance and
debugging difficult and expensive.
•
Avoid using an identifier for multiple purposes:
Each variable should be given a descriptive and meaningful name indicating the reason
behind using it. This is not possible if an identifier is used for multiple purposes and thus
it can lead to confusion to the reader. Moreover, it leads to more difficulty during future
enhancements.
•
Length of functions should not be very large:
Lengthy functions are very difficult to understand. That’s why functions should be small
enough to carry out small work and lengthy functions should be broken into small ones
for completing small tasks.
•
Try not to use GOTO statement:
GOTO statement makes the program unstructured, thus it reduces the understandability
of the program and also debugging becomes difficult.
•
Grouping Code
It is better to group the tasks in different blocks/functions of code separating them with
proper space. You can add a comment at the starting of every block
CODING AND DOCUMENTATION CRITERIA
2
•
Deep nesting structure should be avoided
Too many nesting structures make it difficult to understand the code. It is, therefore,
advisable to avoid using deep nesting
•
Overload layout, Always put overloads next to each other in a class.
•
•
•
•
General purpose Utilities should be separated in Helper project like sending emails.
Each module belongs to separate projects.
Use extension methods in dense code areas like Startup.
Avoid Using Add-ons, locked classes to make sure that all code parts are editable,
configurable & extendable.
• Classes:
o Use method chaining
o Prefer composition over inheritance
To produce loosely coupled types.
• Separation of concerns is a software architecture design pattern/principle for separating
an application into distinct sections, so each section addresses a separate concern. At its
essence, Separation of concerns is about order.
•
Use DTOs & object Mappers.
Testing
•
Single concept per test
o Ensures that your tests are laser focused and not testing miscellaneous (nonrelated) things, forces AAA pattern used to make your codes more clean and
readable
Business documentation criteria:
We highly encourage you to document each module in details and its dependencies (the interrelationships with other modules) we highly encourage drawing the workflow to show graphically
these relationships.
•
Code should be well documented:
The code should be properly commented for understanding easily. Comments regarding
the statements increase the understandability of the code, dead code should be
removed not commented.
CODING AND DOCUMENTATION CRITERIA
3
Front-end coding criteria
1. Define form parameters before Component definition.
2. Variables must be a camelCase.
3. Use renderer addClass, removeClass where possible. It will prevent too many change
detection checks.
4. Try to use get, set on Input() instead ngOnChanges. When you have many Inputs
in the ngOnChanges, each “if” has to be checked.
5. Use pipe when rendering content in ngFor.
6. Specify baseUrl and module aliases (paths) to your compilerOptions to avoid any
inconsistency when importing other files.
7. Add stylePreprocessorOptions to your angular.json file to avoid inconsistency
while importing other files.
8. Keep route names as const. It will prevent accidental typos.
9. Use trackBy in ngFor loops to optimize the re-rendering of iteratable.
10. Use a virtualized scroll list like e.g. CDK Virtual Scroll when you need to display a
very large records collection.
11. Use ngZoneEventCoalescing flag to reduce the amount of change detection
cycles while Event Bubbling.
12. Lazy loading in Angular – instead of loading a complete app, Angular loads only
the modules which are required at the moment. It reduces the initial load time.
13. Always keep an eye on your Bundle Size. Depends on the scale of your project, in
enterprise apps if your main.*.js file exceeds more than 0.5 MB, you may need to
be aware.
14. Use Services for any Side Effects. It is a good place for any HTTP requests, event
handlers, time-based events. It reduces the complexity of the component and
provides reusability to codebase.
15. Preload your resources and routes to speed up your application
16. Use NGRX to manage application state which it is inspired by Redux.
CODING AND DOCUMENTATION CRITERIA
4
17. Use projection as frame to customize your view and don't repeat code more
(design once and use it anywhere).
18. Use Asynchronous Communication wherever possible to avoid wastage of
application resources.
19. Modularize components for reusability. Divide any big components to small
pieces to easy manage it and use input-output ways to communicate them.
20. Try to load component using component factory resolver for dynamic component
loading.
21. Use guards and resolvers to manage roles and navigations auth.
22. Use strongly typed variables, parameters, arguments and please, avoid using
{any}
Security implications
1. Cookies:
a. encrypting the information
b. never use cookies to store highly sensitive or critical information
2. X-XSS-Protection - Preventing Cross-Site Scripting Attacks
3. Use Inputs & Outputs over session variables
4. Encrypt Query strings
5. No use for Paid Services, frameworks, dlls, etc.
6. No use for insecure Add-ons.
Performance implications
•
•
•
Asynchronous code
Use .NET Core 3.1 & Angular 10
Choose appropriate data types with appropriate sizes
CODING AND DOCUMENTATION CRITERIA
5