Four checkpoints to be satisfied before delivering your code

• Coding
• Comments
• Testing
• Git-version control

Coding

Variable name

The naming of variables is crucial to make your code legible. The idea behind naming variables is simple: Create variables that explain what they do and keep a consistent theme across your code. Let’s look at some common name conventions.

Multiword Delimited

This convention is to use no whitespace to separate words in a variable name. Programming languages have a hard time interpreting whitespace within variables. As a result, variables must be separated in some way. Here are a few examples of delimiter conventions that are often used in code:

Pascal case: Capital letters are used to separate words.

VariableOne
VariableTwo

Snake case: An underscore is used to split words.

variable_one
variable_two

Camel case: Except for the first word, uppercase letters are used to separate words.

variableOne
variableTwo

Hungarian Notation: At the start of the variable name, this notation identifies the variable type or purpose, followed by a descriptor that indicates the variable’s function. Words are separated using the Camelcase notation.

arrDistrubuteGroup //Array called “Distribute Group”
sUserName //String called “User Name”
iRandomSeed //Integer called “Random Seed”

Function and Class name

Functions and classes should follow a similar structure of descriptive titles circumscribed by the rules given above, just like variables. The ability to distinguish between classes, functions, and variables is a key aspect of naming. For functions and classes, for example, Camelcase and Pascalcase might be used, while variable names could be written in Snake case or Hungarian notation. Differentiating functions, classes, and variables using distinct naming conventions can considerably assist other readers of your code and minimize the need for extensive amounts of comments.

Function length should not be more than 20 lines

The first rule of function design is that it should be as minimal as possible. Functions should be less than that, according to the second rule. The length of a function should not exceed 100 lines. Functions should never exceed 20 lines in length.

The same logic should not repeat in the entire codebase

Need to remove redundant code or modules. If some of the modules are common then must need to be put in common or helper or utility folders

Comments

Make use of code annotations or tags

Many computer languages have code commenting standards. Java employs the Javadoc code commenting system, whereas JavaScript uses the JSDoc code commenting system, which is supported by a number of documentation creation tools.

For functions, you should include the following code tags:

• @desc — Write down a description for your function
• @param — Describe all input parameters the function accepts. Make sure to define the input types.
• @returns — Describe the returned output. Make sure to define the output type.
• @throws — Describe the error type the function can throw
• @example — Include one or multiple examples that show the input and expected output

Here is the function of add() from lodash library:

import createMathOperation from './.internal/createMathOperation.js'

/**
* Adds two numbers.
*
* @since 3.4.0
* @category Math
* @param {number} augend The first number in an addition.
* @param {number} addend The second number in an addition.
* @returns {number} Returns the total.
* @example
*
* add(6, 4)
* // => 10
*/
const add = createMathOperation((augend, addend) => augend + addend, 0)

export default add

Logic comments

Within functions, logic comments are used to clarify difficult code pathways. It’s an obvious code smell or technical debt, showing that your code is way too sophisticated, as you could have expected.

Furthermore, logical comments can contain far too much detail. The higher the level of detail, the more mess you’ll generate and the less readable your code will be. Here’s an example of an overly detailed code comment.

let date = new Date(); // store today's date to calculate the elapsed time

Remove commented code

Sometimes in the code file, we comment down unused code. So it is bad practice to push code in the release branch.

# def unused_func():
# with open('results.json', 'r') as f:
# data = json.load(f)
# for i in data:
# print(i['desc'])def used_func():
with open('results.json', 'r') as f:
data = json.load(f)
for i in data:
print(i['title'])

Testing

Before delivering your code or module. Test all other endpoints or code is working as like before your changes

Git

Check branch name

• If it’s associated with any tickets then make sure the branch name is connected with its appropriate ticket
• Use branch naming convention as per project management team is following
• Make sure the branch has updated code (Code sync with the appropriate branch) (In the most case branch code connect with the main branch)

Git Flow Branch Strategy

The main idea behind the Git flow branching strategy is to isolate your work into different types of branches. There are five different branch types in total:

• Main
• Develop
• Feature
• Release
• Hotfix

The two primary branches in Git flow are main and develop. There are three types of supporting branches with different intended purposes: feature, release, and hotfix.

Commit message

<type>(<scope>): <short summary>
│ │ │
│ │ └─⫸ Summary in present tense. Not
│ │ capitalized. No period at the end.
│ │
│ └─⫸ Commit Scope:
│ email|payment|payout|crud|animations|bazel
│ |benchpress|common|compiler|compiler-cli|core|
│ |elements|forms|http|language-service|localize|
│ platform-browser|platform-browser-dynamic|
│ platform-server|router|service-worker|upgrade|zone.js
│ |packaging|changelog|docs-infra|migrations
│ |ngcc|ve|etc...
│
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test

Type Must be one of the following:

• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to our CI configuration files and scripts (examples: CircleCi, SauceLabs)
• docs: Documentation only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that neither fixes a bug nor adds a feature
• test: Adding missing tests or correcting existing tests

Example

feat(elements): add support for creating custom elements

Conclusion

To sum up, we have seen various ways to make our code clean and understandable for everyone with a standard format of coding and delivering the best. Furthermore, if you still made mistake? it's okay! cause that is why programmers are here. But be sure to make yourself better at each iteration.