On 2 May 2009, at 12:13, Michael Sheldon wrote:
> Any complaints? Additions?
The if/else formatting in #8 and #9 are different to each other. My
personal preference would be the one used in #9 as it's more
consistent with the suggested formatting for classes and functions.
If we're going to format classes and functions differently from if/
else then we'll also need to decide case-by-case for other curly-
brace-delimited structures, such as foreach, while, switch and for. I
think it's simpler to have a consistent formatting for all structures
that use curly-braces.
Regarding the eternal tab/space question, I'm happy that tabs have
been chosen, but I'd like to point out that while tabs are great for
indenting lines, spaces tend to work better for other source code
formatting, such as lining things up in columns. For example,
interpret double-underscores as tabs and asterisks as spaces in the
following example:
if (true)
{
__$x['foobarbaz']*=*'foobarbaz';
__$x['quux']******=*'quux';
__$x['xyzzy']*****=*'xyzzy';
}
The above style of formatting it more resilient to changes in tab
width and easily allows for each developer to set the tab width in
his or her editor without things starting to look crazy. Thinking
about it, you should notice that the above code will look correct in
a monospaced font at any tab size whereas if you use tabs surrounding
the equals signs, the right hand sides of the assignments will flail
about depending on tab width.
It might be useful to specify line-endings (or does subversion take
care of that automatically?).
Also, I'd suggest specifying that files must be either UTF-8 or ASCII
encoded. (The latter is of course a subset of the former.)
Lastly, although you do see, from time to time, some ghastly over-
commented code, I'd suggest removing rule #6. We don't want to
discourage commenting, and if someone's undecided about whether or
not to comment a particular contribution, I'd rather they did (a
comment can always be removed later). The problem of comments slowing
down the interpretation of PHP code can be virtually eliminated by
employing a PHP accelerator, which acts to cache parsed PHP as
compiled bytecode - i.e. the PHP is compiled once and run many times.
--
Toby A Inkster
<mailto:[email protected]>
<http://tobyinkster.co.uk>
_______________________________________________
Libre-fm mailing list
[email protected]
http://lists.autonomo.us/mailman/listinfo/libre-fm
