Pretty printing automatically formats source code into a readable layout. It balances horizontal space, vertical space, and indentation: keep lines within a typical width, reveal structure through indentation, and insert as few line breaks as possible. These goals conflict, so formatting policy becomes an algorithmic design problem. section 9.0 section 9.1
A simplified formatter makes the problem precise and separates its main transformations:
- Parse source text into a parse tree; parsing itself is outside the formatter’s core treatment. section 9.4
- Transform the tree into an immutable doc describing grouping, indentation, and possible line breaks. section 9.4
- Render the doc into source code that fits the desired page width, using an iterative greedy algorithm. section 9.5
- Use an explicit stack when the doc graph becomes deeper than the parse tree, avoiding call-stack overflow from deep recursion. section 9.5
- Keep formatting rules separate from parse-tree classes with the visitor pattern, allowing multiple analyses or formatting policies. section 9.4
A formatting choice with competing goals
Given `if (outdated) Update(); CreateReport();`, a formatter might keep everything on one line, or break after the condition and indent `Update()`. The latter uses more vertical space but makes the control-flow structure clearer. The simplified problem excludes comments, tabs, required statement breaks, and language-specific quirks; it permits only spaces and line breaks with four-space indentation. section 9.1
double Frob(int x){int y = Qux(x); return Rezrov(y+1);}
Compare compact and irregularly spaced source with the same expression structure, motivating normalization by a pretty printer. section 9.0
