...one of the most highly
regarded and expertly designed C++ library projects in the
world. — Herb Sutter and Andrei
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 ;
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 ;