What you'll be able to do

By the end of this page you should be able to name a variable so a tired person can guess what it holds, put spaces and line breaks where humans expect them, and stop treating semicolons as either a religion or a mystery. Clean code at this stage is not “enterprise architecture.” It is making your file readable enough that the next error is easier to find.

Previous post: variables — let, const, and var.

Who this is for

  • People whose first files look like one long line pasted from three different websites
  • Beginners who name everything a, data, or temp2 and then cannot debug an hour later
  • Anyone who got a weird error after deleting a semicolon “because the other tutorial did not use them”

You can skip this if your names already describe the value, your editor formats on save, and you are consistent about semicolons in a file. Come back when a teammate (or future you) cannot read a snippet you wrote last week.

Names that say what they hold

A name is a short sentence for a value. JavaScript does not care if you call something x. You will care at 11 p.m.

Scenario A — a score on a page. let n = 0; tells you nothing. let clickCount = 0; tells you it is a number that grows when someone clicks. When the console later says clickCount is not defined, you know which idea broke.

Scenario B — a button from the page. const b = document.getElementById("go"); is fast to type and slow to read. const goButton = document.getElementById("go"); matches the HTML id and the job of the element. If you have two buttons, goButton and resetButton stay distinct; two variables named b and b2 do not.

JavaScript names for ordinary variables use camelCase: start lowercase, then capitalize the next word — userName, maxScore, isOpen. Do not start a name with a number. Do not put spaces in a name. const user name = "Raman" is a SyntaxError; const userName = "Raman" is a statement.

Booleans (true/false values) often read better with is, has, or can: isReady, hasError. You do not need that prefix on every flag, but let flag = true is how files become unreadable.

When not to over-name: const city = "Pune" is already clear. const nameOfTheCityTheUserSelectedOnTheHomeScreen is a paragraph pretending to be a variable. Aim for a short, honest label.

Semicolons in daily code (not a holy war)

A semicolon ; ends a statement, the way a period ends a sentence. JavaScript can often insert them for you (automatic semicolon insertion). That is why some examples work without them.

Scenario A — a normal file, one statement per line.

const city = "Pune";
console.log(city);

With or without the semicolons, this usually runs. In this series we keep them, because they make “this instruction is finished” visible, and they match a lot of professional JS you will copy later.

Scenario B — the case that bites people who delete every semicolon.

const score = 1
[score].forEach(function (n) {
  console.log(n)
})

Depending on how the engine glues those lines, this kind of pattern can throw or do something you did not mean, because a line starting with [ can look like it belongs to the line above. You do not need to memorize every ASI rule today. You need one practical habit: in a given file, be consistent, and if a strange error appears right after you removed semicolons, put them back on those statements and see if the error moves.

Do not mix styles in one file — some lines with ;, some without — just because you pasted from two blogs. Pick one (this series uses semicolons) and format the paste to match.

Formatting so copied code stops looking random

The engine mostly ignores extra spaces and line breaks (inside strings it does not). Humans do not ignore them.

Scenario A — one mashed line.

const button=document.getElementById("go");button.addEventListener("click",function(){console.log("hi")});

This can run. It is miserable to edit. You cannot see where the function starts. A SyntaxError on “line 1” is useless when line 1 is the whole program.

Scenario B — the same logic, spaced like a person.

const button = document.getElementById("go");

button.addEventListener("click", function () {
  console.log("hi");
});

Spaces around =, a blank line between “find the button” and “listen for clicks,” and the function body indented one level. Indentation is not decoration. It shows what belongs inside what.

If your editor has Format Document (VS Code: right-click, or Shift+Alt+F on Windows), use it on beginner files. You are not cheating. You are making the next error readable.

Quotes: ' and " both work for strings. Do not open with one and close with the other. In a file, pick one style and stick to it. This series uses double quotes in examples unless a string contains a double quote.

A small cleanup exercise

Here is a messy snippet a beginner might paste. Rewrite it in your editor until names, spaces, and semicolons are consistent — then run it in a tiny HTML file.

Messy:

let a=0;const b=document.getElementById("out")
function x(){a=a+1;b.textContent="n="+a}
document.getElementById("go").addEventListener("click",x)

One clean version:

const out = document.getElementById("out");
const goButton = document.getElementById("go");
let clickCount = 0;

function addOneClick() {
  clickCount = clickCount + 1;
  out.textContent = "n=" + clickCount;
}

goButton.addEventListener("click", addOneClick);

Same behavior. Different chance of surviving a week. a became clickCount, b became out, x became addOneClick. You can argue about those exact words; you cannot argue that x was a good name for a click handler.

Mistakes I see a lot

1. Copying three tutorials into one file without reformatting. One uses var and no semicolons, one uses const and Prettier spacing, one uses single quotes. The file then looks “broken” even when it runs. Format the whole file to one style after every paste.

2. Names that describe types instead of jobs. const string1 = "Pune" is weaker than const city = "Pune". You already know it is a string from the quotes.

3. Fighting the editor’s formatter, then blaming JavaScript. If Format Document moves braces, let it. Brace style is less important than consistency.

4. Tiny names in a five-line demo that later grows. i is fine in a short loop later in the series. i as your only page-level variable is how “what is i?” becomes a daily question.

What to try before the next post

  1. Take any file you already wrote in this series and rename b / n / x to words you would say out loud.
  2. Run Format Document once and look at the diff. Keep the result if it is easier to read.
  3. In one file, add semicolons to every statement (or remove them all), not a mix, then run the file again.
  4. Paste the messy snippet above, clean it, and confirm the button still updates the paragraph.

This closes Phase 1 of the series (absolute start). Next we begin values: the types you actually meet — number, string, boolean, null, undefined, and typeof surprises like typeof null.

Try this next outside the series

Once the absolute basics feel clear, leave the series for one practical browser step and one simple tool you can use right now.

javascripttutorialsdevelopers