Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
const currentDate = moment().format("YYYY/MM/DD");

Use explanatory names for functions.

This goes without saying, try to explain what the function is doing in its name, it shouldn’t have the words: Func, function, handle, do, execute or any similar to those.

Bad:

Code Block
handleSubmit(){} (From our code base)

Good:

Code Block
submitCropForm(){} | submit(){}

Name CONSTANTS.

Random numbers, strings or booleans in our code that actually hold meaning makes our code hard to understand. (refer to)

...

Code Block
class Animal {
  constructor(animalType, animalColor, animalName){}
}

Also Bad:

Code Block
const animalList = ['Frog', 'Cat', 'Mouse'];

...

This is quite simple to understand, if you are replacing a piece of code, feel free to delete it entirely, remember, we are using version control, if you later find out, you need that code, just checkout to the previous commit and get it back.

Commenting guidelines

First things first, you probably shouldn’t comment every method or variable you create on the codebase, if functionality is clear enough, there is no need to add additional context to it, so e.g.

Code Block
function removeLetterA(arrayOfStrings) {
  return arrayOfStrings.map(string => string.replace('A', ''));
}

Is a pretty good example of self commented code, there is probably no need to write anything else to it. It's clear the function is used to remove the letter A from an array of strings you, it returns a new arrayOfStrings without letter A.

However, there are a lot of cases where complexity can’t be simply described by convenient naming or beautiful code. In those cases, making use of comments is a good idea.

Where to comment?

If there is a function which has some complexity inherent to it, is convenient to make. a comment explaining what it does, how it does it, explaining complex regexes if there exists one, etc. The place to comment, is in the header of the function, just above it. Not in the actual function code. Avoid doing:

Code Block
function retrieveFromDB(data, id){
  if(id.contains('4')){
    // Then we need to do this because of this
    doThis(data);
  } else {
    // do the other thing because is not this
    doTheOther(data);
  }
  retrieve(data);
}

Trying to explain your code inside a function forces the reader to read the whole thing, to understand what is being done, and incites you as the writer of the comment to write comments to coupled with the context of the code.

Instead, try to write comments that explain, what the function does ? What parameters does it receive? and what does it return? I will do this following the JS Doc “syntax”

Code Block
/*
* Retrieves data from the database 
* @param {object} Describe the data parameter here
* @param {string} Describe the id parameter here
* @returns {void} Describe the return value
*/
function retrieveFromDB(data, id) {
  if(id.contains('4')){
    doThis(data);
  } else {
    doTheOther(data);
  }
  retrieve(data);
}

You will see, after just one example, its much easier to see that function and understand what it does without actually reading its code! Which is our goal here.

I recommend you follow the JS Doc syntax on functions that are too complex to read, and on which parameter variables or return values are not clear upon reading the function name or usage.