15 Rules For Writing Clean JavaScript

Mohammad Faisal - May 9 '23 - - Dev Community

To read more articles like this, visit my blog

So you are a React developer or Node.js developer. You can write code that works. But can you write code that is visually beautiful and understandable by others?

Today we will see some rules to make your JavaScript code clean and clear.

Rule 1. Don’t Use Random Characters as Variable

Don’t use some random character to express a variable.

//BAD 

const x = 4;
Enter fullscreen mode Exit fullscreen mode

Name your variable properly so that it describes the value properly.

//GOOD

const numberOfChildren = 4;
Enter fullscreen mode Exit fullscreen mode

Rule 2. Use camelCase Variable Name

Don’t use snake_case, PascalCase, or a variable name that starts with a verb.

// Bad: Begins with uppercase letter 

var UserName = "Faisal"; 

    -----

// Bad: Begins with verb 

var getUserName = "Faisal"; 

    -----

// Bad: Uses underscore 

var user_name = "faisal";
Enter fullscreen mode Exit fullscreen mode

Instead, use a camel-cased variable name that represents a noun.

// Good

const userName = "Faisal";
Enter fullscreen mode Exit fullscreen mode

Rule 3. Use Good camelCase Function Name

Don’t use any noun as a function name to avoid confusion with the variable names.

// Bad: Begins with uppercase letter 
function DoSomething() {  
    // code 
} 

    ----

// Bad: Begins with noun 
function car() {  
    // code 
} 

    ----

// Bad: Uses underscores 
function do_something() {  
    // code 
}
Enter fullscreen mode Exit fullscreen mode

Instead, start the name with a verb and use camel case.

//GOOD

function doSomething() {
    // code
}
Enter fullscreen mode Exit fullscreen mode

Rule 4. Use PascalCase For Constructor Function Naming

// Bad: Begins with lowercase letter 
function myObject() {  
    // code 
} 

    ----

// Bad: Uses underscores 
function My_Object() {  
    // code 
} 

    ----

// Bad: Begins with verb 
function getMyObject() {  
    // code 
}
Enter fullscreen mode Exit fullscreen mode

Also, Constructor function names should begin with a nonverb because new is the action of creating an object instance.

// GOOD

function MyObject() {  
    // code 
}
Enter fullscreen mode Exit fullscreen mode

Rule 5. Global Constants

Global constants whose value doesn't change should not be named like normal variables.

// BAD

const numberOfChildren = 4;

// BAD 

const number_of_children = 4;
Enter fullscreen mode Exit fullscreen mode

They should be all upper case and separated with underscores.

// GOOD

const NUMBER_OF_CHILDREN = 4;
Enter fullscreen mode Exit fullscreen mode

Rule 6. Assignment to Variable

Don’t assign a comparison value to a variable without parentheses.

// BAD 

const flag = i < count;
Enter fullscreen mode Exit fullscreen mode

Use parentheses around the expression:

// GOOD

const flag = (i < count);
Enter fullscreen mode Exit fullscreen mode

Rule 7. Usage of Equality Operators

Don't use “==” or “!=” to compare values. Because they don't type check before comparison.

//BAD

if (a == b){
    //code
}
Enter fullscreen mode Exit fullscreen mode

Instead, always use “===” or “!==” to avoid type coercion errors.

//GOOD

if (a === b){
    //code
}
Enter fullscreen mode Exit fullscreen mode

Rule 8. Usage of the Ternary Operator

Don’t use the ternary operator as an alternative to if statement:

//BAD

condition ? doSomething() : doSomethingElse();
Enter fullscreen mode Exit fullscreen mode

Only use them to assign values based on some condition:

// GOOD

const value = condition ? value1 : value2;
Enter fullscreen mode Exit fullscreen mode

Rule 9. Simple Statement

Although JavaScript supports it. Don’t write multiple statements in a single line.

// BAD

a =b; count ++;
Enter fullscreen mode Exit fullscreen mode

Instead, have multiple lines for multiple statements. And always use a semicolon at the end of a line.

// GOOD

a = b;
count++;
Enter fullscreen mode Exit fullscreen mode

Rule 10. Use of If Statements

Don’t omit the braces from an if statement and never keep them in a single line.

// BAD: Improper spacing 
if(condition){  
    doSomething(); 
} 

    ----

// BAD: Missing braces 
if (condition)  
    doSomething(); 

    ----

// BAD: All on one line 
if (condition) { doSomething(); } 

    ----

// BAD: All on one line without braces 
if (condition) doSomething();
Enter fullscreen mode Exit fullscreen mode

Always use braces and proper spacing:

// GOOD

if (condition) {
    doSomething();
}
Enter fullscreen mode Exit fullscreen mode

Rule 11. Usage of For Loop

Don’t declare the variable in the initialization of a for loop.

// BAD: Variables declared during initialization 

for (let i=0, len=10; i < len; i++) {  
    // code 
}
Enter fullscreen mode Exit fullscreen mode

Declare them before the loop.

// GOOD

let i = 0;

for (i=0, len=10; i < len; i++) {  
    // code 
}
Enter fullscreen mode Exit fullscreen mode

Rule 12. Consistent Indentation Length

Stick to using 2 or 4 all the time.

// GOOD

if (condition) {
    doSomething();
}
Enter fullscreen mode Exit fullscreen mode

Rule 13. Line Length

Any line should not be more than 80 characters. If it’s more than that they should be broken up into a new line.

// BAD: Following line only indented four spaces doSomething(argument1, argument2, argument3, argument4,
    argument5); 

    ----

// BAD: Breaking before operator 
doSomething(argument1, argument2, argument3, argument4
        ,argument5);
Enter fullscreen mode Exit fullscreen mode

The second line should be indented **8 spaces **instead of 4 and shouldn't start with a separator.

// GOOD
doSomething(argument1, argument2, argument3, argument4,
        argument5);
Enter fullscreen mode Exit fullscreen mode

Rule 14. Primitive Literals

Strings shouldn’t use a single quote.

// BAD

const description = 'this is a description';
Enter fullscreen mode Exit fullscreen mode

Instead, they should always use double-quotation

// GOOD

const description = "this is a description";
Enter fullscreen mode Exit fullscreen mode

Rule 15: Use of “undefined”

Never use the special value undefined.

// BAD

if (variable === "undefined") {  
    // do something 
}
Enter fullscreen mode Exit fullscreen mode

To see if a variable has been defined, use the typeof operator

    // GOOD

    if (typeof variable === "undefined") {  
        // do something 
    }
Enter fullscreen mode Exit fullscreen mode

So by following these rules, you can make your JavaScript projects cleaner.

These rules are taken from the book “Maintainable Javascript” written by “Nicholas C. Zakas”. So if you don’t agree with some of the points, I guess that’s fine. When it comes to styling there is no single way. But the rules here can be a good starting point for you.

That’s it for today. Happy Coding! :D

Get in touch with me via LinkedIn or my Personal Website.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .