Here's how to declare a variable in JavaScript using the var keyword with the example number = 100.

Variables in JavaScript are like little labeled jars that hold data you want to use later. Think about how you’d keep a number handy for a calculation or a name you’ll display somewhere in your app. The moment you know how to declare that jar, your code starts to feel manageable, almost predictable. So, let’s break down the classic way to create a variable and what it means for your code.

The old-school way: var number = 100;

Here’s the thing. Among the options you might see in a quiz or a quick exercise, var number = 100 is the traditional declaration. It creates a variable named number and gives it the value 100. That line is straightforward, and it works in all JavaScript environments, including older browsers. The code looks simple:

• var number = 100;

• console.log(number); // 100

That little line has a lot of history behind it. “var” has function scope, which means the variable is accessible throughout the function it’s declared in, or globally if declared outside any function. It’s a design choice that can surprise you in larger scripts, because the variable can creep into places you didn’t expect.

But why does this matter? Because scope is how JavaScript keeps things organized. If you declare number with var inside a function, it’s only visible inside that function. If you forget you’re inside a function and you’re trying to grab number from outside, you might run into bugs. And there’s hoisting to think about too—where a var declaration is moved to the top of its scope at compile time, while the assignment stays where you wrote it. Translation: you can reference number before you actually assign it, and you’ll get undefined, not an error. Let me explain with a tiny example:

function showNumber() {

console.log(number); // undefined, because var is hoisted

var number = 100;

console.log(number); // 100

}

showNumber();

That’s the subtle edge var brings to the party. It’s not chaos, but it does require a bit of mental juggling about what’s visible where and when.

Modern cousins: let and const

If you peek at today’s JavaScript code, you’ll see let and const popping up all the time. They’re the newer ways to declare variables, and they bring block scope to the table. Block scope means each pair of curly braces creates a tiny, private space for your variable—inside if statements, loops, or any nested blocks. That tends to make code easier to reason about.

• let age = 25; declares a variable age that lives only in the block where you put it.

• const pi = 3.14159; makes a constant binding—the value can’t be reassigned.

A quick mental model: var is like a hallway you can walk through from end to end; let and const are rooms with doors that close when you leave the block. If you try to use a let or const declared inside a block from outside, you’ll get a ReferenceError. It’s a small difference, but it changes how you structure functions and loops.

And yes, let and const are hoisted too, but they’re not initialized until their actual line runs. That means if you try to read a let or const before its declaration, you’ll crash with a ReferenceError. It’s a gentle reminder to declare variables before you use them, which helps prevent a lot of bugs.

Choosing the right tool for the job

In most modern code, let and const are the go-tos. Use:

• const when you know the binding won’t change. It communicates intent clearly and helps prevent accidental overwrites.

• let when you know the value will change, such as a counter in a loop or a value you reassign based on user actions.

There are still times when var makes sense, especially if you’re maintaining older code or need compatibility with very old environments. Some teams keep a few var declarations for that reason, but most new code leans on let and const for readability and fewer surprises.

Common gotchas to watch for

• Omitting a declaration (num = 100) isn’t safe in strict mode; you’ll get an error. In non-strict mode, it creates a global variable, which can leak into other parts of your program and bite you later.

• Re-declaring a var inside the same scope is allowed; re-declaring let inside the same scope isn’t. That difference helps catch typos and logic mistakes.

• Reassignment with const isn’t allowed, but the contents of an object or array assigned to a const can still be changed. The binding is constant, not the value itself—there’s a subtle but critical distinction there.

A practical glance: a tiny sample you can relate to

Imagine you’re building a small feature that tracks a user’s visit count and a flag for whether they’ve seen a welcome message.

• var visits = 1; // traditional, function/global scoped

• let hasSeenWelcome = false; // can toggle to true later

• const MAX_VISITS = 5; // constant, not to be reassigned

If you later decide to bump visits after a successful login, you’d do visits = visits + 1; That’s straightforward with var or let, but with const you’d need a different mechanism since you can’t rebind MAX_VISITS.

The human side of variables

Code is about people as much as about machines. When you pick between var, let, and const, you’re deciding how your future self (and teammates) will read and reason about the script. A name like number, age, or MAX_VISITS should convey intent. If you see MAX_VISITS in all caps, you expect that value to stay put. If you see age changing in a loop, you expect a moment where the value grows or shrinks. Clear naming paired with the right declaration keyword makes your code feel friendly rather than mysterious.

Let me explain the practical takeaway

• Start with const by default. It signals intention and makes your code safer from accidental reassignments.

• Switch to let when you know a value will change, like a counter in a loop.

• Use var only if you’re dealing with legacy code or a situation that requires function-scoped behavior in environments where let/const aren’t fully supported.

If you’ve ever seen a quiz question that asks “Which one declares a variable correctly?” and the answer is var number = 100;, you’re not alone. It’s the classic form that has stood the test of time. But in real projects, you’ll mostly see let and const, with a few var hints for compatibility. The point isn’t to memorize a rule for its own sake; it’s to understand how the tool you’re using shapes what your code can do—or what it might accidentally do.

A few friendly analogies to anchor the concept

• Think of var as the open shelf in a shared pantry: anyone in the function can grab or change it.

• Think of let as a personal jar in your kitchen cabinet: you’re free to adjust it, but only you can reach it in that tight space.

• Think of const as a locked jar with a label: the label won’t change, and you won’t swap the content easily.

Real-world tips you can apply today

• When you’re starting a new project or reading someone else’s code, scan for var usage. If you don’t need wide access, replace var with let or const to gain better scoping control.

• Use ESLint or a similar tool to enforce consistent variable usage—most teams configure rules that prefer const and let over var.

• In debugging, remember where a variable is declared. If a value behaves oddly, check whether hoisting or scope is the culprit.

Pulling it together

Variable declarations are one of the first things you’ll touch in JavaScript, and they set the stage for everything else you’ll build. The line var number = 100 stands out as the classic way to create a variable, and it’s still perfectly valid today. Yet, the modern approach leans toward block-scoped declarations with let and const, which helps your code stay clean and predictable. Understanding the difference between function/global scope and block scope makes you a better reader of code—and a sharper writer of it.

If you’re curious about how real-world apps manage data, try a small hands-on exercise: declare a few variables using var, then rewrite the same snippet with let and const. Observe how they behave inside a function, inside a loop, and inside a conditional block. You’ll notice the way they’re treated by the JavaScript engine, and you’ll feel more confident when you code.

In the end, the goal isn’t just to know the right syntax. It’s to write code that’s clear, resilient, and easy for others to follow. The variable declarations you choose become a quiet promise to yourself and your teammates: you’ll keep data organized, predictable, and ready for the next feature you’re itching to build. And that makes the whole journey through JavaScript a little easier to love.