[Owncloud] Coding guidelines for codesniffer and CI

[Thomas Tanghus]

On Thursday 19 July 2012 02:26 Jörn Friedrich Dreyer wrote:
> [extend] We extend the guidelines on http://owncloud.org/dev/contribute/
> to create the level of detail needed for PHP CodeSniffer and gradually
> increase the number of checks over time
> 
> [adopt] We adopt a standard code style like PEAR [1] or Squiz and go
> from
> there<http://www.squizlabs.com/php-codesniffer/how-much-does-your-standard-c
> heck>. PEAR was meant to increase readability and Squiz is very strict [2].
> PEAR for example reqires a space between control structures and
> brackets: "} else {" instead of "}else{".

Actually I couldn't find the Squiz coding guidelines from that link, and 
searching for it linked to some very raunchy sites :-D 
 
> Personally, I vote for the adoption of a mix of PEAR and Squiz as a
> solid base where we add our current guidelines, eg: use tabs to indent
> and placement of brackets.

I can live with PEAR violations as high priority, even though I would prefer 
opening brackets on the same line as class and function definitions, but it's 
more important that we have a common style. Then maybe add some more warnings 
as normal priority:

- Missing spaces between string concatenators (my spell checker doesn't like 
that word ;) ) and operators.

- Use of alternative syntax such as  endif;, endwhile;, endfor;, endforeach;, 
or endswitch; It just looks butt-ugly when mixed with 'normal' syntax ;)

- Maybe be more lax with constructs like <?php }; ?> in templates (until 
ownCloud uses TAL as default ;) )

 - My personal pet peeve: Use curly brackets around logical blocks even if 
it's a one-liner.

> What is your opinion?
> 
> [1] http://pear.php.net/manual/standards.php
> [2]
> http://www.squizlabs.com/php-codesniffer/how-much-does-your-standard-check

btw: why, why why was it decided to use tabs? <ducking and hiding>

-- 
Med venlig hilsen / Best Regards

Thomas Tanghus