Hi Dave, I'm not currently subscribed to the p6 lists but noticed your
guidelines while browsing.
I'd like to see some more 'should's in the layout section; in particular:
- binary operators should have a space on either side;
- parentheses should not have space immediately after the opening paren
nor immediately before the closing paren
- commas should have space after but not before
.. giving:
x = (a + b) * f(c, d / e);
I'd also like to see a specification for indentation when breaking long
lines. I've seen various styles used; my own preference is that a) long
lines should be broken _before_ an operator, so that it is immediately
obvious when scanning the LHS of the code that this has happened; b)
that where possible, we break out the contents of a matched pair of
parens, and if so introduce an extra level of indentation for the
contents:
do_arbitrary_function(
list_of_parameters_with_long_names, or_complex_subexpression(
of_more_params, or_expresssions + 1
)
);
.. or _two_ extra levels of indentation in any other case:
long_named_variable = long_named_variable_2 + long_named_variable_3
+ long_named_variable_4 + long_named_variable_5
+ long_named_variable_6;
(I've used 2-space indents throughout in the above examples.)
These pretty much correspond to the format I use for preference in both
my C code and my Perl code, and I find them a substantial aid to
readability. In particular, the more consistent the indentation and
spacing of the code, the easier I find it is to read the code and the
more readily bugs tend to stand out.
HTH,
Hugo
