...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
At some point, especially when there are lots of semantic actions attached to various points, the grammar tends to be quite difficult to follow. In order to keep an easy-to-read, consistent and aesthetically pleasing look to the Spirit code, the following coding style guide is advised.
This coding style is adapted and extended from the ANTLR/PCCTS style and Boost Library Requirements and Guidelines and is the combined work of Joel de Guzman, Chris Uzdavinis, and Hartmut Kaiser.
program = program_heading [heading_action] >> block [block_action] >> '.' | another_sequence >> etc ;
"program"
instead of PROGRAM
, '>='
instead of GTE
and '.'
instead of DOT
.
This makes it much easier to read. If this isn't possible (for instance
where the used tokens must be identified through integers) capitalized
identifiers should be used instead.
*(','
>> file_identifier)
as long as the line does not exceed
80 characters.
program_heading = no_case["program"] >> identifier >> '(' >> file_identifier >> *( ',' >> file_identifier ) >> ')' >> ';' ;
identifier = no_case [ lexeme [ alpha >> *(alnum | '_') [id_action] ] ] ;
'!'
, '+'
etc.) should be moved out one space before the corresponding indentation
level, if this rule has a body or a sequence after it, which does not
fit on on line. This makes the formatting more consistent and moves the
rule 'body' at the same indentation level as the rule itself, highlighting
the unary operator.
block = *( label_declaration_part | constant_definition_part | type_definition_part | variable_declaration_part | procedure_and_function_declaration_part ) >> statement_part ;