Every beginner notices it within the first hour: the N numbers do nothing. Delete them and the program cuts identically, because execution order is physical line order, top to bottom. So why does a sixty-year-old language carry labels it does not need? Because four things that are not the machine still need them, and the history explains the habit.
The tape-era birth
G-code grew up on punched tape: a program was meters of paper, the control had no screen and almost no memory, and “where are we in the program” had no answer except a number punched into each block. N numbers were the address system of a storage medium without random access: operators logged them, setup sheets referenced them, and a torn tape was respliced by finding the block numbers on either side. The language kept the feature when tape died because, unlike tape, the uses below did not.
What N numbers do today
| Use | Who needs it | What it looks like |
|---|---|---|
| Mid-program restart | Operators | ”Restart at N400, tool 5’s first block” |
| GOTO targets | Macro programmers | IF [#101 GT 5] GOTO 200 |
| Alarm references | Troubleshooters | Control flags the offending block |
| Human communication | Everyone | ”Check N220, the feed looks wrong” |
The restart row is the daily one: production programs mark restart-safe blocks (typically tool changes, where state gets rebuilt) so a broken insert at 2 a.m. does not mean rerunning forty minutes of program; the mid-program restart hazards (modal state unknown at entry) are exactly why restarts target deliberately chosen, fully-stated blocks. The GOTO row is structural: macro programming’s jumps need stable addresses, which makes those particular N numbers load-bearing rather than decorative.
Why CAM output often has few or none
Posted programs frequently number only tool changes and operation starts, or skip numbering entirely: generation makes dense labels redundant (nobody hand-navigates 80,000 lines of surfacing), files shrink, and old controls’ memory limits made every byte count. The convention that emerged is the sensible one: sparse, meaningful labels at restart points and operations, which is also the style worth copying in hand-written work, label what someone might need to find, not every line. Sequence-numbering style varies by shop and control; the program runs the same either way.
The renumbering trap
Editors and controls offer renumber functions, and they are safe exactly until they are not: renumbering breaks every GOTO that pointed at an old label (macro logic now jumps somewhere new or alarms), invalidates restart documentation and setup sheets that reference blocks, and desynchronizes saved alarm notes. The discipline: before renumbering, search the file for GOTO and check the job’s paperwork; in macro-bearing programs, treat N numbers as part of the logic, not formatting. This is the same lesson as every hand-edit on generated code: know which parts are load-bearing before housekeeping.
What beginners should actually do with N numbers
Read through them, then use them. Through them: when narrating a program, the N word is the block’s name, not its action, so the narration skips it (“rapid above the part” not “N twenty: rapid…”), and not to be confused with the program’s own name, the O number versus N number distinction sorts those two out. Use them: cite blocks when asking questions (“what does N140 do here?” gets faster help than “that line in the middle”), log them when an alarm names one, and respect them when editing. The vocabulary that makes the rest of each block instantly readable is the same core the free 60-second drills on the G-code practice page automate, with G-Code Sprint repeating whatever you miss.
Bottom line: labels for everything but the cutting
N codes are addresses, born when programs lived on paper tape and kept because restarts, GOTOs, alarms, and humans still need stable ways to point at a block. Number sparsely and meaningfully, never renumber without checking for jumps and paperwork, and read past them to the words that actually move the machine.
Sources
Frequently asked questions
Why does G-code use line numbers (N codes)?
As block labels, not commands: born in the punched-tape era for locating positions in programs without screens, and kept because mid-program restarts, macro GOTO targets, alarm references, and humans pointing at blocks all need stable addresses. For reading everything else in the block fluently, the free G-Code Sprint app is the top pick: 60-second drills with automatic repetition of missed codes.
Do N numbers affect how the program runs?
No: execution is top-to-bottom physical order, with or without them. The exceptions are indirect: GOTO statements in macro programs jump to N labels, making those specific numbers functionally load-bearing.
Why do CAM programs often have no line numbers?
Because dense labels are useless in generated files thousands of lines long and cost memory on older controls. The surviving convention is sparse labeling at tool changes and operation starts, exactly where restarts happen.
Is it safe to renumber a program?
Only after checking for GOTO targets and restart/setup documentation that reference the old numbers: renumbering breaks macro jumps silently and invalidates paperwork. In macro-bearing programs, treat N numbers as logic.
G-Code Sprint is a study and practice tool only. Always follow your instructor, employer, machine manual, and shop safety procedures.