P-2.2 An Editor That Helps You

What this is and why it exists

An editor set up properly removes a whole category of mistake before it costs you a run. Most people never turn those features on.

Three of them matter. Jumping to a definition. Automatic formatting. A linter reading your code while you type.

There is one confusion worth clearing first. Formatting is often treated as a matter of taste worth arguing about. Its real value is that nobody has to think about it at all.

The vocabulary

• Project — a whole directory opened as one unit, rather than a single file.
• Symbol — a name in code: a function, a variable, a type.
• Go to definition — jumping to where a name was declared.
• Find all references — listing everywhere a name is used.
• Formatter — a tool that rewrites layout to one fixed style.
• Linter — a tool that reads code and reports problems without running it.
• Breakpoint — a marked line where a running program pauses so you can look at it.

The mental model

Open a project, not a file. This one change is the foundation for everything else. An editor that can see the whole directory can resolve names across files, and resolving names is what makes jumping to a definition possible. Open single files and you have a text box with colours in it.

With the project open, you can read unfamiliar code the way it is meant to be read. Follow a name to where it is defined. Ask where else it is used. Doing this by searching for text works until two things share a name, and in any real codebase two things always share a name.

Formatting comes next, and it should run on save. The argument for it is not that one layout is prettier. It is that the difference between two versions of a file then contains only what somebody meant to change. Reviewing a change becomes possible, because the noise is gone.

A linter reports two quite different things, and this is where most people go wrong. Some of what it says is a harmless habit. Some of it is a genuine mistake that would have cost you an hour. If both arrive with the same urgency, you will learn to ignore all of it. So configure it until what it reports is worth reading, then read it.

Last, run and stop your program from inside the editor. Set a breakpoint, pause, and inspect everything at once. For anything with more than a few moving parts this beats adding print statements. It is the same debugger from the failure topic, with a friendlier front.

What you should now be able to explain or do

Open a project rather than a file, and say why that changes what the editor can do. Navigate by symbol instead of by scrolling. Say why text search stops working on a real codebase. Run a formatter on save, and give the real reason for it. Configure a linter so its output is worth reading. Set a breakpoint and inspect values instead of printing them.

Check yourself