Files, Functions, and Variables

A real program is not one long list of instructions. It is organized, and the organization exists purely for humans. The machine would be perfectly happy with a single unbroken stream of steps. People would not. So code is arranged into three nested layers you will meet everywhere: files, functions, and variables.

Files: the shipping unit

Programs live on disk as ordinary text files. Small tools fit in one file. Large projects split across hundreds, each holding one area of responsibility, connected by import or require statements that say this file uses that one. The file is also the unit you ship, sell, and, when the time comes, protect: when someone talks about obfuscating their script, they mean transforming the text inside a file.

Functions: named bundles of steps

Inside a file, instructions group into functions: a named sequence of steps that can be run on demand, given inputs, and asked for an output. Instead of copying the same ten lines everywhere, you write them once, name the bundle, and call it by name.

// a function: named steps, inputs in, output back
function applyDiscount(price, percent) {
  const saved = price * percent / 100;
  return price - saved;
}

const finalPrice = applyDiscount(200, 15);

Read that code out loud and notice how much you understood without being taught. Apply discount. Price. Percent. Saved. The names carry the story. That is exactly what good code does, and exactly what obfuscation will later take away.

Variables: named values

The smallest unit of organization is the variable: a name attached to a value the program is currently remembering. finalPrice is a variable. So are price, percent, and saved. Programs are full of them, and choosing clear names is most of what separates readable code from noise.

Names are free documentation

Here is the observation this whole lesson is building to. The machine does not need any of these names. It would run the same program if the function were called q7 and the variables were a, b, and c. Names exist only to inform whoever reads the file, and they inform every reader, including ones you never intended.

Prove it to yourself. The program below runs the same computation twice: once with honest names, once with the names scrubbed to nothing. Press Run and compare the two printed results, then try renaming the scrubbed half to anything you like. The machine never notices.

Every name in your code is a note to the reader, and you do not get to choose who the reader is. When a lesson in Level 6 shows identifier renaming destroying names, this is the information it is destroying.

There is a precise way to say this: names, comments, and layout are semantically inert. Strip them all and the program's behaviour is bit-for-bit identical, which is why renaming is always safe for the machine and always costly for the human. The reverse is also true and it matters for Level 5: when attackers read code, recovering good names for things is most of the actual work of understanding it. Tools can undo formatting in milliseconds. Nothing can automatically recover a deleted name, because the name was never in the machine's copy of the meaning at all.

Summary: files, functions, and variables organize code for people, not machines. Names are free documentation for whoever holds the file, the machine never reads them, and that asymmetry is exactly what identifier renaming exploits when you reach the technique lessons.

Frequently asked questions