General rules

Coding standards are designed to make source code easier to understand and develop, to ensure basic code quality, and to make it easier for multiple people to collaborate on a project.

ATTENTION

All rules and standards must be followed!

At the same time, they can be adapted to a specific project.

Naming conventions

Each language has its own naming conventions that must be followed.

For example, in JavaScript you should use lowerCamelCase 99% of the time, but in C# you should use lowerCamelCase and UpperCamelCase, depending on the situation.

If you do not know these generally accepted standards or you have any doubts, be sure to read them and follow them.

For example, here are conventions for C#.

Code duplication

Code duplication is not only two identical code fragments, but also two code fragments that are very similar to each other.

ATTENTION

Dode duplication is STRICTLY PROHIBITED, even if only one line is duplicated!

If you have code duplicaiton, your code is bad.

Read this article from Refactoring to understand how to avoid this issue.

Use early return (guard clause)

Use a technique such as exiting a method early in case "something went wrong". This will allow you to avoid a lot of if/else and confusing hard-to-read code.

Read the following articles to understand the issue:

• Should I return from a function early or use an if statement?

• Replace Nested Conditional with Guard Clauses

• If-statements design: guard clauses may be all you need

Long methods (spaghetti)

Methods longer than 30 lines should start to worry you. Your methods should be short and clear. All auxiliary actions that occur inside the method should be moved to separate methods.

TIP

You should follow this rule: if you feel the need to comment something inside the method, it is better to separate this code into a new method.

It makes sense to separate even one line into a method if it needs clarification. In addition, if the method has a good name, then you will not need to look at its code to understand what it does.

Read this article from Refactoring to understand how to avoid this issue.

Constants and enums

ATTENTION

Always use named constants or enums instead of any literals in your code.

Correct:

if (addressType === AddressType.Work) {
    .....
}

Wrong:

if (addressType === 2) {
    .....
}

if (addressTypeName === "Home") {
    .....
}

Thanks to constants and enums, the code becomes clear, and the value is stored in only one place, which allows you to quickly find and change it.

Indentation

Always use four spaces for indentation. Never mix tabs with spaces.

Using proper indentation and nesting is the most important aspect for easy code readability, so take it seriously.

TIP

Make sure that when you use Tab, your IDE self replaces tab characters with spaces and that the tab size is equal to four spaces - this is the default setting in Visual Studio.

Correct:

<ul>
    <li>Five</li>
    <li>Six</li>
</ul>

Comments

Use comments to explain your code: what it does, what it is responsible for, and why the chosen solution is being used. Commenting on business logic is especially important. At the same time, balance is important - you should not comment on obvious things.

TODO marks

If you leave any tasks in the code for last, mark them with the TODO keyword. Almost all IDEs offer code analysis for the presence of TODO blocks in it.

Describe the task after a colon, for example: TODO: Task.

Example:

<!-- TODO: Remove redundant options -->
<ul>
    <li>Cucumbers</li>
    <li>Tomatoes</li>
</ul>