| Helgi Žormar 2005-01-16, 3:56 am |
| What I find most important is the new line stuff (allow 1 and 2x, hence
flexibility) and the indent stuff, that is the this:
switch () {
case 'foo':
}
What we should be concern about is how the rest is indented really,
that's matter of taste.
The reason why I brought this up is because I'm making a QA CS checking
script which uses the PHP Beautifier (package in PEAR) to get that goal.
What the script will do is check out all PEAR packages (well probably
just spider out from the CVS link which developers provide on the
package description page), checkout the code (I just have to make some
magics on checking out something which is none PHP.net, SF.net or any of
the other public repos) then it runs the checks, makes some diffs and
provides the pear-qa ML only with a link to those diffs and those that
are interested can see if their package is among those and apply those
diffs.
Now I wanted to get this part of the CS into the spotlight since I think
it's as is to restricting (thus I guess the beautifier acts as
restrictive), plus a little discussion doesn't kill people :)
For those that are more interested in this script I'm talking about,
I'll probably also make it check for php syntax errors and something
mombo jombo like that, and it will hopefully help people :)
Note I won't make it run from any php.net machine, this doesn't even
have to be some "official" PEAR QA thing, just something for me really,
so I'll find a out side source to host this (hopefully dotg but I
haven't talked enough to David about this)
Anyway hope this cleared things a little up _why_ I started this thread
:)
- Helgi
On Sat, 2005-01-15 at 08:30, Davey wrote:
> Sean Coates wrote:
>
> <snip>
>
> Personally, I find that the next "case *:" tells me where
> the previous block ended or the closing brace.
>
> I prefer
>
> switch (foo) {
> case 1:
> action1;
> break;
> case 2:
> action2;
> break;
> }
>
> This means its easier to see the list of case conditions, and I don't
> need to mentally block out the "break;"'s
>
> Still, its very trivial, I think we shouldn't force the user either way
> on this point, except to that it should be one or the other.
>
> - Davey
|