DEV Community

John Au-Yeung
John Au-Yeung

Posted on

Coding Conventions for Writing JavaScript

Subscribe to my email list now at http://jauyeung.net/subscribe/

Follow me on Twitter at https://twitter.com/AuMayeung

Many more articles at https://medium.com/@hohanga

Even more articles at http://thewebdev.info/

Like any other programming language, JavaScript has its own conventions that developers should follow. There are a lot of rules to follow, but there are some key basic ones that affect code in the whole program.

Why We Need JavaScript Coding Conventions?

Having conventions make things easier to understand since codebases follow the same patterns.

Naming and declaration of variables, functions, classes, and other entities are consistent in their naming scheme. This means that we can understand code easier and makes things more predictable.

White space, indentation, and comments make code easy to read and don’t clutter up the screen.

Also, maintenance is faster since it’s easier to understand and trace. This makes debugging more effective.

Variables and Functions

Variable names should be camel case. This also applies to functions.

Names should start with a letter.

For example, the following is good:

let birthDay;

However, the following is not:

let 123birthday;

Classes

Class names start with an upper case letter and the rest are camel case, which is also called Pascal case.

There should be one space before the opening curly brace and the closing curly brace should be on a new line with no space before it.

For example, the following is good:

class Person {}

And the following is bad:

class person {}

Constants

Constants should be all upper case. So the following is good:

const FOO = 1;

Dollar Sign

Lots of libraries start their identifier names with the dollar sign. Therefore, to avoid conflict, we should start our identifiers with something else.

Spacing Around Operators

There should be one space between the operand and the operator for binary operators, like +, -, =, *, / and after commas.

For example, the following is good:

let x = y + z;

However, the following is bad:

let x=y+z;

Comma-separated items should have one space after the comma. For example, the following is good:

foo(1, 2, 3);  
[1, 2, 3];

But the following code is bad:

foo(1,2,3);  
[1,2,3];

Code Indentation

2 spaces for indentation is the accepted convention for indentation:

For example, the following is good:

function foo() {  
  let x = 1;  
}

But the following is bad:

function foo() {  
     let x = 1;  
}

It’s better to use spaces instead of tabs since tabs are interpreted differently by different programs and operating systems.

Many text editors can convert tabs to 2 spaces by changing their settings or adding plugins to do it.

Statements

Statements should end with a semicolon at the end.

For example, the following is good:

let x = 1;

But this is bad:

let x = 1

Omitting semicolon is bad because where the line ends is ambiguous. This is hard to read for developers, and the JavaScript interpreter might not run the code the way you think it does.

For example, if we have:

if (x === 1)  
  foo();  
  bar();

Then we might think that foo and bar both run when x is 1, but actually, only foo runs since only foo(); is considered to be in the if block.

For complex statements, we should put curly braces around the block and semicolons at the end of each line to make everything clear.

Also, there should be one space before the opening bracket. The closing bracket should be in a new line without any leading spaces. Complex statements shouldn’t end with a semicolon even though it’s allowed.

For instance, we should write functions like:

function foo() {  
  let x = 1;  
}

Conditional statements should be like:

if (x === 1) {  
  y = 1;  
} 
else {  
  y = 0;  
}

and loops should be like:

for (let i = 1; i <= 10; i++) {  
  y = x;  
}

Object Literals

Object literals should have space before the opening curly bracket and it should be on the same line as the object name. Properties inside should be left of the colon with no space before it. The value, which is right of the colon, should have one space before it.

The last property shouldn’t have a comma after it.

Quotes should be wrapped around strings only.

The closing bracket should be on a new line with no space before it. Finally, the object literal definition should end with a semicolon.

The following is an example of object definition code with good spacing:

let foo = {  
  a: 1,  
  b: 2,  
  c: 3  
}

Shorter objects can also be compressed into one line, with spaces separating the properties as follows:

let foo = { a: 1, b: 2 };

Avoid Long Lines

Lines shorter than 80 characters are preferred for easy reading on smaller screens. We can break long lines into shorter ones by putting the remainder of the line on the next line.

File Names

Windows filenames aren’t case sensitive. However, most other operating systems have case sensitive file names. Therefore, it’s best to name them all lower case to avoid issues with file name casing.

There’re lots of rules to follow. However, many text editors have text formatting features to clean up the spacing. The other ones can be fixed with a Linter or a program like Prettier to prettify the code.

Top comments (6)

Collapse
 
mateiadrielrafael profile image
Matei Adriel • Edited

What is this stuff?!?!

First of all, all js engines can work with semicolonless code, this isn't a convention and I know a lot of people who do not use them.

Same for the 2 indentation one, I know a lot of people who prefer 4 spaces instead of 2.

The dollar sign at the end is a convention for all observable values in the rxjs community, so ir shouldn't be simply avoided.

Also, you cannot even run code with the variable name 123somethimg because variable mames cannot start with numbers.

Not trying to be rude but how am I supposed to belive an article written by a guy who starts loops at 1 and ends them when the counter <= the end

Collapse
 
devdufutur profile image
Rudy Nappée

You certainly misreaded, he says don't use a $ as a prefix not as a suffix.

And even if you can use semiconlonless code, it shouldn't mean you have to. Semicolons improve readability of your code. Look at default configurations of JS code formatters like prettier...

(1) for (let i = 0; i < arr.length; i++)

is strictly equivalent to

(2) for (let i = 1; i <= arr.length; i++)

Even if I don't use this second form, some could argue it's more human readable (humans starts counting at 1 as far as i know).

Collapse
 
mateiadrielrafael profile image
Matei Adriel • Edited

A convention is something people decided is the best way to do somrthing. Since a lot of people don't use seimcolons it just means it's not a convention

Also, 99% of people start loops at 0, so why do it the other way around in a post about "conventions"

Collapse
 
devdufutur profile image
Rudy Nappée

I agree with almost each of these conventions.

However, in FP, you use a lot of "const", I don't think it's a good idea to have almost all your (un)variables in UPPER_CASE.

I would use UPPER_CASE only for global constants and still use camelCase for local constants.

Collapse
 
mateiadrielrafael profile image
Matei Adriel

I agree with that, UPPER_CASE give me #define vibes (not saying that's a bad thing, but it's weird to do it anywhere but st the global level / for stuff like functions)

Collapse
 
aumayeung profile image
John Au-Yeung

That's not a bad idea. I think consistency is more important than the case in this situation.