Coding good practices ​

This is list of coding syntax often seen in PRs, that should be avoided, and should be checked when reviewing PRs (WIP).

1. Unnecessary condition

   js

   if (someCondition) return false;
   return true;

   if (someCondition) return false;
   return true;

   can be easily written to

   js

   return someCondition;

   return someCondition;

2. Unnecessary else

   js

   if (isLeaving) return "hello";
   else return "bye";

   if (isLeaving) return "hello";
   else return "bye";

   or

   js

   if (isLeaving) {
       return "hello";
   } else {
       return "bye";
   }

   if (isLeaving) {
       return "hello";
   } else {
       return "bye";
   }

   the else statement is redundant here, the code should be rewritten to

   js

   if (isLeaving) return 'hello'
   return 'bye

   if (isLeaving) return 'hello'
   return 'bye

3. Not using destructuring

   js

   if (this.someValue === 5) {
     if (this.someValue > this.otherValue) {
       return this.someValue + this.otherValue
     } else if (this.otherValue > this.someValue + 50)
       return this.someValue - this.otherValue
     }
     return this.someValue
   } else {
     return this.someValue + 5
   }

   if (this.someValue === 5) {
     if (this.someValue > this.otherValue) {
       return this.someValue + this.otherValue
     } else if (this.otherValue > this.someValue + 50)
       return this.someValue - this.otherValue
     }
     return this.someValue
   } else {
     return this.someValue + 5
   }

   This type of code is very hard to read because no destructuring is applied. It can get specifically difficult when naming is longer and nesting is deeper. Same code with destructuring:

   js

   const { someValue, otherValue } = this
   
   if (someValue === 5) {
     if (someValue > otherValue) {
       return someValue + otherValue
     } else if (otherValue > someValue + 50)
       return someValue - otherValue
     }
     return someValue
   }
   
   return someValue + 5

   const { someValue, otherValue } = this
   
   if (someValue === 5) {
     if (someValue > otherValue) {
       return someValue + otherValue
     } else if (otherValue > someValue + 50)
       return someValue - otherValue
     }
     return someValue
   }
   
   return someValue + 5

Naming ​

Naming is difficult. There's always debate among developers about correct naming, and it's easy to judge each others' work on this aspect. The important aspects of applying naming is to be consistent, to think just a sec longer and to keep in mind if somebody else will understand what you're doing.

In general variable and function names should state what they do. As a rule of thumb it's better to use long names than short ones:

scopeOptions doesn't say much except that it provides or has options. A more clear naming is scopeOptionsForSelectDropDown. This makes it exactly clear what the intend of the variable or method is.

Booleans should start with is or has. This makes sure their value answers to their own naming, for example isLoading hasError isItem

Constants must be capitalized, for example const GHG_SCOPE = "Scope 1"

As a good practice, before you commit try to review the naming you have selected, and try to imagine if the naming will be clear for an external dev.

Here are some other recommendations regarding naming variables.

Arbitrary values as constants ​

If you need to use values in your code that probably appear to be arbitrary to another developer, make sure to either avoid those (best option) or declare them as constants:

Don't

const importantValueNeeded = someArray.at(5);

const importantValueNeeded = someArray.at(5);

Do

const INDEX_OF_IMPORTANT_VALUE = 5;
const importantValueNeeded = someArray.at(INDEX_OF_IMPORTANT_VALUE);

const INDEX_OF_IMPORTANT_VALUE = 5;
const importantValueNeeded = someArray.at(INDEX_OF_IMPORTANT_VALUE);

Commenting ​

Yes, code should be self-documenting, and when you've named your variables correctly it should be understandable for other devs. However, there are always situations that you need to do something specific, some hack to avoid some weirdness, or apply some complicated business logic. In that case make sure to comment your code!

We use JSDoc standards for inline documentation, more details can be found:

• JSDoc guidelines