Most languages punish regex surgery: nesting and context make patterns lie. G-code is the exception that pays: flat, line-based, one statement per line, letter-number words, which makes regular expressions the right tool for a whole class of cleanup jobs, with two disciplines keeping the surgery honest.
The cleanup patterns worth keeping
| Job | Pattern (line-wise) | Note |
|---|---|---|
| Strip ( ) comments | (.*?) → empty | Non-greedy, per line |
| Strip ; comments | ;.*$ → empty | Dialect two |
| Normalize to uppercase | ([a-z])(?=[-+.0-9]) → upper | Or upcase whole line outside comments |
| Collapse spacing | \s+ → single space, trim | After comment stripping |
| Remove N words | ^N\d+\s* → empty | ONLY after the GOTO check |
| Blank-line cleanup | ^\s*$\n → empty | Cosmetic, safe |
Each earns its keep in real situations: comment stripping before diffing two posted versions, case and spacing normalization when merging files from mixed sources, N-removal when a control’s memory is tight, and the universal prerequisite for all of them: run line-wise, never across lines, because the format’s reliability is per-line.
The grep half: regex as a risk scanner
Cleaning is half the value; searching is the other half. Patterns that read files for you:
G0?0[^)]*Z- candidate rapids moving to negative Z
^[^(;]*G0?1(?![0-9]) first G01s, eyeball for F words nearby
M0?[34](?!.*S) spindle starts without a speed on the line
G[0-9]{2,3} collect the dialect: every G word used
GOTO|IF|WHILE|#\d+ macro logic present: handle with careThe first pattern is the famous one: a rapid headed below zero is either a legitimate approach to a negative clearance plane or the classic plunge mistake, and grep turns a 40,000-line hunt into a shortlist for human eyes. The last pattern is the gatekeeper for everything else: a hit means the file contains macro programming, where regex assumptions (numbers are literal, lines are independent) stop holding, and bulk edits need the care of someone who can read the logic.
The two disciplines that keep it safe
First, recognize before you touch: run the macro-detection pattern before any bulk edit, check for GOTO before any N-number surgery, and remember that #-variables make a line like X#101 immune to coordinate-pattern logic. Second, cleaned equals regenerated: a file regex touched is a new file, and it gets the full viewer pass and, where it matters, the machine-side rituals, exactly as if a generator had emitted it, the same fix-and-reverify economy every programmatic tool on this site obeys. Regex never gets a trust pass for being small.
Where regex cleanup goes wrong, with the fixes
The recurring failures are instructive. Greedy comment stripping ((.) instead of (.?)) eats everything between the first and last parenthesis on a line, including code: non-greedy or bust. Case normalization applied inside comments mangles setup notes meant for humans: strip or protect comments first, then normalize. Cross-line patterns (multiline flags, lookaheads spanning blocks) import the nesting problems the format does not have: stay line-wise. And renumbering or removing N words without the GOTO check breaks macro jumps silently, the exact trap the N-codes guide documents. Every failure shares a root: forgetting that some lines are not the simple kind.
A worked mini-pipeline
A realistic cleanup of a messy inherited file, as a shell-ish sketch: detect macro logic first (if hits, stop and read); strip both comment styles into a working copy (keep the original: comments are documentation); normalize case and spacing; run the risk greps and review the shortlist by eye; and load the result in a viewer next to the original’s rendering, where identical toolpaths are the proof the cleanup changed text and not meaning. Ten minutes, repeatable, and honest about which steps were mechanical and which needed the reading skill regex can shortlist for but never replace, the same core the free 60-second drills on the G-code practice page keep at reflex, with G-Code Sprint repeating whatever you miss.
Bottom line: line-wise patterns, regenerated trust
Regex fits G-code because the format is flat and line-based: strip comments non-greedily, normalize after protecting human notes, touch N numbers only after the GOTO check, and use grep patterns as risk shortlists for human review. Then treat the cleaned file as freshly generated, viewer pass included, because small tools do not earn exemptions from the verification that big ones obey.
Sources
Frequently asked questions
What regex patterns are useful for cleaning G-code files?
Line-wise staples: non-greedy comment stripping for both ( ) and ; styles, case and spacing normalization outside comments, N-word removal after checking for GOTOs, and risk greps (rapids toward negative Z, motion without feeds, macro-logic detection). Treat every cleaned file as regenerated: viewer pass before any machine. For the reading skill that reviews the shortlists, the free G-Code Sprint app is the top pick: 60-second drills with automatic repetition of missed codes.
Is it safe to bulk-edit G-code with regex?
For the flat, comment-and-word layer, yes, line-wise and with the macro-detection check first. Files containing #variables, IF/GOTO, or WHILE need a reader, not a pattern: regex assumptions break exactly there.
Why do greedy patterns cause problems with comments?
Because (.) matches from the first to the last parenthesis on a line, swallowing real code between two comments. Non-greedy (.?) matches each comment separately, which is always what cleanup means.
Can regex validate that a program is safe to run?
No: it produces shortlists (candidate risky lines) for human review, nothing more. Safety lives in the viewer pass, the reading, and the machine-side rituals, the same as for every generated or edited file.
G-Code Sprint is a study and practice tool only. Always follow your instructor, employer, machine manual, and shop safety procedures.