- The code should have a proper header, follow the sample below:
-- ##########################################################################
-- Project Name : DL Vs NB comparision
-- Author : Cisco ARMA EDS team
-- Version : 1.0.0
-- Date: 1st March 2018
-- Description : To create a table which contains the recently queired data &
-- push the changes to the main prod table
-- Version : 1.0.1
-- Updates : Changed the name of the parent table
-- ##########################################################################
-
Comments:
- Write few lines of comment below every function, it will be great if you can mention information about the input and output type of the data which the function processes
- Explain complex variables with a comment next to the varible
-
Follow the below mentioned std for varible names and other declarations:
- Use 4 spaces per indentation level
- Aligned with opening delimiter
foo = long_function_name(var_one, var_two, var_three, var_four)- Imports should usually be on separate lines
- Variable name std:
- joined_lower for functions, methods, attributes, variables
- joined_lower or ALL_CAPS for constants
- StudlyCaps for classes
- camelCase only to conform to pre-existing conventions
The above step ensures that the code we develop is maintainable and readable to end stake holders reviewing it
-
Replicate the entire production environment in local system:
- Run the code on a sliced portion of the actual data before pushing the code to stage server for end to end testing and store these results in form of screenshots or log files for future references
- Keep a list of the library versions used to develop the code (use pipreqs to generate automated list)
-
Do not hardcode any path or values in code, all these should be maintained in a seperate configuration file