Difference between revisions of "Pretty Printer"
(Added a new page about Pretty Printer) |
m (Added a list of open bugs) |
||
| Line 26: | Line 26: | ||
Apart from the visual style the formatting should preserve the original code. This allows for completely automated validation of the tool. If there is a generator of source code streams from the given grammar, the generated text can be feed to the tool. Then the input and output can be compared side by side after serializing them into a sequence of tokens. If the sequences match, the conversion went without an error. Otherwise it renders a bug in the tool. | Apart from the visual style the formatting should preserve the original code. This allows for completely automated validation of the tool. If there is a generator of source code streams from the given grammar, the generated text can be feed to the tool. Then the input and output can be compared side by side after serializing them into a sequence of tokens. If the sequences match, the conversion went without an error. Otherwise it renders a bug in the tool. | ||
| + | == Known bugs == | ||
| + | Next is the list of open bugs related to pretty printer: | ||
| + | * bug#17557 | ||
| + | * bug#17568 | ||
| + | * bug#17575 | ||
| + | * bug#17580 | ||
| + | * bug#17581 | ||
| + | * bug#17582 | ||
| + | * bug#17585 | ||
| + | * bug#17586 | ||
| + | * bug#17588 | ||
| + | * bug#17591 | ||
| + | * bug#17603 | ||
| + | * bug#17608 | ||
| + | * bug#17609 | ||
Latest revision as of 00:49, 20 June 2011
Background
The tool can be used to reformat the source code in a standard way that follows the recommended style. It can be invoked either from the command line by the corresponding command or in IDE via the menu entry. The tool does not address all coding rules, but only those related to text layout: indentation, spacing, new lines, etc.
Options
Not all processing expectations are covered by the rules. Some of them may affect resulting code and are therefore controlled by optional settings.
| Option | Affected constructs | Example | Recommended setting |
|---|---|---|---|
| Shall trailing white space be stripped? | Comments | -- "[ -- Trailing spaces -- ]" |
True |
Limitations
Some language constructs are difficult to format automatically without breaking original idea of the formatting. These include:
- inline comments: when used inside larger construct they break normal text flow and it may be difficult to guess how the construct should be continued on a new line
Testing
The eweasel tests that address potential or found and fixed issues are tagged with the keyword pretty and use prettyNNN for test directory names.
Apart from the visual style the formatting should preserve the original code. This allows for completely automated validation of the tool. If there is a generator of source code streams from the given grammar, the generated text can be feed to the tool. Then the input and output can be compared side by side after serializing them into a sequence of tokens. If the sequences match, the conversion went without an error. Otherwise it renders a bug in the tool.
Known bugs
Next is the list of open bugs related to pretty printer:
