Declaring and calling your first function

Everything you have written so far runs the moment the program reaches it. Line 1, then line 2, then line 3, top to bottom, once each. That is fine for a program that does one thing once. It falls apart the moment you want the same three lines to happen in four different places, because the only tool you have so far is copying them and pasting them again.

A function is the fix. It is a set of steps that you write down once, give a name to, and — this is the part that matters — that do NOT run when the program reaches them. They sit there, named and ready, until somewhere else in the program you say the name and ask for them. Writing them down is one event. Running them is a completely separate event that can happen zero times, once, or two hundred times.

Hold on to that separation. Almost every confusing thing about functions comes from mixing up those two moments. When you are reading a function's body, nothing is happening yet: you are reading instructions, not results.

Think of a recipe card for pancakes. Writing the card is not cooking. You can write it out, pin it to the fridge and go to bed, and no pancakes appear. The card is a set of steps with a name at the top — Pancakes — waiting for somebody to follow it.

Following the card is cooking. Someone picks it up, does what it says, and pancakes come out. They can follow it again tomorrow and again next week, and each time is a fresh run of the same written steps. Nobody rewrites the card each morning.

In JavaScript, writing the card is called declaring a function. Following it is called calling the function. The rest of this lesson is the notation for those two things, and nothing more.

A function declaration is four things in a row: the keyword function, the name you are giving it, a pair of round brackets, and a pair of curly braces holding the steps. The steps inside the braces are called the function body. Everything inside those braces is the recipe; none of it happens yet.

Calling it is much shorter: write the name, then a pair of round brackets. Those brackets are the whole instruction. They mean do it now. The name on its own, with no brackets, is just the name — it refers to the function without running it, the same way saying the word pancakes does not make breakfast.

Function names follow the same rules as any other name in JavaScript, and the convention is to use a verb: greet, printBanner, calculateTotal. If you cannot think of a verb for it, that is usually a sign the function is trying to do more than one thing.

The obvious win is not repeating yourself. Four copies of the same three lines means four places to change when the requirement changes, and the bug is always in the copy you forgot.

The bigger win is the name. Once a chunk of behaviour is called calculateDeliveryFee, the code that uses it reads as a list of intentions instead of a wall of arithmetic. You can follow what a program is trying to do without holding every detail in your head at once, and that is the difference between code you can work on and code you can only stare at.

The third win is that a bug now has one home. When delivery fees come out wrong, there is exactly one function to open. That single property is what makes a program of ten thousand lines possible at all.

Before your program runs, JavaScript reads through it and sets up every function declaration it finds in that scope. By the time the first line actually executes, all of those names already refer to their functions. The visible effect is that a function declaration can be called from a line above the one that declares it. The official name for this is hoisting.

A usable mental model: the engine does a quick pass to collect the recipe cards and pin them all to the fridge, and only then starts cooking from the top of the list. This is true of function declarations specifically — the form that starts with the keyword function. There are other ways to make a function, and lesson four shows one that does not behave this way at all.

Do not read hoisting as permission to scatter declarations at random. Most code still reads better with a deliberate order. It is worth knowing because otherwise perfectly correct code can look impossible.

Forgetting the brackets. Writing greet; instead of greet(); is not an error, and that is what makes it nasty. JavaScript evaluates the name, gets the function, and throws it away. Nothing prints, nothing breaks, and there is no message anywhere. If a function seems not to run, check for the brackets before you check anything else.

Expecting a printed value to be usable. A function that only calls console.log has put characters on the screen for a human to read; it has not handed anything back to the code that called it. Those are two different acts with two different notations, and the second one is the whole subject of lesson three.

Declaring inside something else by accident. If a declaration ends up inside another function's braces, the name only exists inside those braces, and calling it from outside is a ReferenceError. Lesson five gives that rule its proper name — scope — but the symptom is worth recognising now.

A function declaration writes down named steps without running them. A call — the name followed by round brackets — runs them. The two are separate events, and the same declaration can be called any number of times. Declarations are hoisted, so a call may appear above the declaration it uses. A function that only prints hands nothing back to its caller, which is the gap lesson three fills.