JavaScript Style Guide and Coding Conventions

Always utilize a similar coding traditions for all your JavaScript projects.

JavaScript Coding Conventions

Coding traditions are style rules for programming. They commonly cover:

  • Naming and announcement rules for factors and functions.
  • Rules for the utilization of void area, space, and comments.
  • Programming rehearses and principles

Coding traditions secure quality:

  • Improves code readability
  • Make code upkeep easier

Coding traditions can be recorded standards for groups to pursue, or simply be your individual coding practice.

Variable Names

At welookups we use camelCase for identifier names (factors and functions).

All names begin with a letter.

At the base of this page, you will locate a more extensive discourse about naming rules.

firstName = "John";
lastName = "Doe";

price = 19.90;
charge = 0.20;

fullPrice = cost + (cost * tax);

Spaces Around Operators

Always put spaces around administrators ( = + - */), and after commas:


var x = y + z;
var values = ["Volvo", "Saab", "Fiat"];

Code Indentation

Always utilize 4 spaces for space of code blocks:


work toCelsius(fahrenheit) {
    return (5/9) * (fahrenheit - 32);

Statement Rules

General rules for basic statements:

  • Always end a straightforward explanation with a semicolon.


var esteems = ["Volvo", "Saab", "Fiat"];

var individual = {
    firstName: "John",
    lastName: "Doe",
    age: 50,
    eyeColor: "blue"

General rules for complex (compound) statements:

  • Put the opening section toward the finish of the first line.
  • Use one space before the opening bracket.
  • Put the end section on another line, without driving spaces.
  • Do not end a mind boggling articulation with a semicolon.


work toCelsius(fahrenheit) {
    return (5/9) * (fahrenheit - 32);


for (I = 0; I < 5; i++) {
    x += i;


on the off chance that (time < 20) {
    welcoming = "Good day";
} else {
    welcoming = "Good evening";

Object Rules

General rules for item definitions:

  • Place the opening section on indistinguishable line from the item name.
  • Use colon in addition to one space between every property and its value.
  • Use cites around string esteems, not around numeric values.
  • Do not include a comma after the last property-estimation pair.
  • Place the end section on another line, without driving spaces.
  • Always end  an item definition with a semicolon.


var individual = {
    firstName: "John",
    lastName: "Doe",
    age: 50,
    eyeColor: "blue"

Short items can be composed compacted, on one line, utilizing spaces as it were between properties, as this:

var individual = {firstName:"John", lastName:"Doe", age:50, eyeColor:"blue"};

Line Length < 80

For coherence, keep away from lines longer than 80 characters.

If a JavaScript proclamation does not fit on one line, the best spot to break it, is after an administrator or a comma.


document.getElementById("demo").innerHTML =
    "Hello Dolly.";
Try it Yourself »

Naming Conventions

Always utilize a similar naming tradition for all your code. For example:

  • Variable and work names composed as camelCase
  • Global factors written in UPPERCASE (We don't, yet it's very common)
  • Constants (like PI) written in UPPERCASE

Should you use hyp-hens, camelCase, or under_scores in factor names?

This is an inquiry software engineers frequently talk about. The appropriate response relies upon who you ask:

Hyphens in HTML and CSS:

HTML5 characteristics can begin with (information amount, information price).

CSS utilizes hyphens in property-names (textual style size).


Many software engineers want to utilize underscores (date_of_birth), particularly in SQL databases.

Underscores are frequently utilized in PHP documentation.


PascalCase is frequently favored by C programmers.


camelCase is utilized by JavaScript itself, by jQuery, and other JavaScript libraries.

Loading JavaScript in HTML

Use straightforward linguistic structure for stacking outer contents (the sort quality isn't necessary):

File Extensions

HTML records ought to have a .html expansion (not .htm).

CSS records ought to have a .css extension.

JavaScript documents ought to have a .js extension.

Use Lower Case File Names

Most web servers (Apache, Unix) are case touchy about document names:

london.jpg can't be gotten to as London.jpg.

Other web servers (Microsoft, IIS) are not case sensitive:

london.jpg can be gotten to as London.jpg or london.jpg.

If you utilize a blend of upper and lower case, you must be very consistent.

If you move from a case coldhearted, to a case delicate server, even little mistakes can break your web site.

To stay away from these issues, dependably use lower case record names (if conceivable).


Coding traditions are not utilized by PCs. Most guidelines have little effect on the execution of programs.

Indentation and additional areas are not critical in little scripts.

For code being developed, lucidness ought to be favored. Bigger generation contents ought to be minified.