Coding standards and best practices

Itznur07
5 min readJun 29, 2022

Coding Style For every developer & Programmers — How to write standard code

image from google

Coding Style

Our code must be as clean and easy to read as possible.

That is actually the art of programming — to take a complex task and code it in a way that is both correct and human-readable. A good code style greatly assists in that.

How to Write Standards Code — 7 Best Practices

  1. Syntax
  2. Curly Braces
  3. Line Length
  4. Indents
  5. Semicolons
  6. Nesting Levels
  7. Function Placement

Syntax

  • A space between parameters
  • No space between the function name and parentheses between the parentheses and the parameter
  • Indentation
  • Curly brace { on the same line, after a space
  • Spaces around operators
  • spaces
  • A space after for/if/while
  • A semicolon; is mandatory
  • A space between arguments
  • Lines are not very long
  • An empty line between logical blocks
  • } else { without a line break
  • Spaces around a nested call

Curly Braces

In most JavaScript projects curly braces are written in “Egyptian” style with the opening brace on the same line as the corresponding keyword — not on a new line. There should also be a space before the opening bracket, like this:

if (condition) { // do this // …and that // …and that }

A single-line construct, such as if (condition) doSomething(), is an important edge case. Should we use braces at all?

Here are the annotated variants so you can judge their readability for yourself:

  1. 😠 Beginners sometimes do that. Bad! Curly braces are not needed:
  • if (n < 0) {alert(`Power ${n} is not supported`);}
  1. 😠 Split to a separate line without braces. Never do that, easy to make an error when adding new lines:
  • if (n < 0) alert(`Power ${n} is not supported`);
  1. 😏 One line without braces — acceptable, if it’s short:
  • if (n < 0) alert(`Power ${n} is not supported`);
  1. 😃 The best variant:

if (n < 0) { alert(`Power ${n} is not supported`); }

For a very brief code, one line is allowed, e.g. if (cond) return null. But a code block (the last variant) is usually more readable.

Line Length

No one likes to read a long horizontal line of code. It’s best practice to split them.

For example:

// backtick quotes ` allow to split the string into multiple lines
let str = `
ECMA International's TC39 is a group of JavaScript developers,
implementers, academics, and more, collaborating with the community
to maintain and evolve the definition of JavaScript.
`;

And, for if statements:

if (
id === 123 &&
moonPhase === 'Waning Gibbous' &&
zodiacSign === 'Libra'
) {
letTheSorceryBegin();
}

The maximum line length should be agreed upon at the team level. It’s usually 80 or 120 characters.

Indents

There are two types of indents:

  • Horizontal indents: 2 or 4 spaces.
  • A horizontal indentation is made using either 2 or 4 spaces or the horizontal tab symbol (key Tab). Which one to choose is an old holy war. Spaces are more common nowadays.
  • One advantage of spaces over tabs is that spaces allow more flexible configurations of indents than the tab symbol.
  • For instance, we can align the parameters with the opening bracket, like this:
  • show(parameters, aligned, // 5 spaces padding at the left one, after, another ) { // ... }
  • Vertical indents: empty lines for splitting code into logical blocks.
  • Even a single function can often be divided into logical blocks. In the example below, the initialization of variables, the main loop and returning the result are split vertically:
  • function pow(x, n) { let result = 1; // <-- for (let i = 0; i < n; i++) { result *= x; } // <-- return result; }
  • Insert an extra newline where it helps to make the code more readable. There should not be more than nine lines of code without a vertical indentation.

Semicolons

A semicolon should be present after each statement, even if it could possibly be skipped.

There are languages where a semicolon is truly optional and it is rarely used. In JavaScript, though, there are cases where a line break is not interpreted as a semicolon, leaving the code vulnerable to errors. See more about that in the chapter Code structure.

If you’re an experienced JavaScript programmer, you may choose a no-semicolon code style like StandardJS. Otherwise, it’s best to use semicolons to avoid possible pitfalls. The majority of developers put semicolons.

Nesting Levels

Try to avoid nesting code too many levels deep.

For example, in the loop, it’s sometimes a good idea to use the continue directive to avoid extra nesting.

For example, instead of adding a nested if conditional like this:

for (let i = 0; i < 10; i++) {
if (cond) {
... // <- one more nesting level
}
}

We can write:

for (let i = 0; i < 10; i++) {
if (!cond) continue;
... // <- no extra nesting level
}

A similar thing can be done with if/else and return.

For example, the two constructs below are identical.

Option 1:

function pow(x, n) {
if (n < 0) {
alert("Negative 'n' not supported");
} else {
let result = 1;
for (let i = 0; i < n; i++) {
result *= x;
}
return result;
}
}

Option 2:

function pow(x, n) {
if (n < 0) {
alert("Negative 'n' not supported");
return;
}
let result = 1; for (let i = 0; i < n; i++) {
result *= x;
}
return result;
}

The second one is more readable because the “special case” of n < 0 is handled early on. Once the check is done we can move on to the “main” code flow without the need for additional nesting.

Function Placement

If you are writing several “helper” functions and the code that uses them, there are three ways to organize the functions.

  1. Declare the functions above the code that uses them:
  • // function declarations function createElement() { ... } function setHandler(elem) { ... } function walkAround() { ... } // the code which uses them let elem = createElement(); setHandler(elem); walkAround();
  1. Code first, then functions
  • // the code which uses the functions let elem = createElement(); setHandler(elem); walkAround(); // --- helper functions --- function createElement() { ... } function setHandler(elem) { ... } function walkAround() { ... }
  1. Mixed: a function is declared where it’s first used.

Most of the time, the second variant is preferred.

That’s because when reading code, we first want to know what it does. If the code goes first, then it becomes clear from the start. Then, maybe we won’t need to read the functions at all, especially if their names are descriptive of what they actually do.

Credit On Javascript.info

--

--

Itznur07

Hi, I’m Nur . I’m a Witter in medium.com . I’m Share a lot of tips with you. thanks for visiting my profile .