Like me – this is quite obviously based on K&R, and I thing K&R is stupid, hard to read, and should have been stamped out ages ago.
For starters the excess spaces around assignment and mathematic operators; I always find that harder to read – t o m e t h a t’s l i k e s p a c i n g a s e n t e n c e l i k e t h i s!
For example:
for ($i = 0; $i < 10; $i++) {
I’ve always found hard to follow, can’t tell what’s what; if the spaces were restricted to between statements, and for bitwise comparitors…
for ($i=0; $i<10; $i++) {
It is many times clearer for me – I mean, sure, it’s only four spaces, you wouldn’t think that would make it harder… it sure does for me… again, is everyone else punctuation blind or something? Or is it that for the first decade I did programming not one programming language I used even allowed spaces to be placed in that manner? (or stripped them out after you entered a line)
On the other hand I heartily approve of this
if ($expr1) {
// if body
} elseif ($expr2) {
// elseif body
} else {
// else body;
}
Putting the opening brace on it’s own like (K&R) I find hard to read, hard to follow, and defeating the point of indenting. Honestly, I think php would be better if it lost the curly braces altogether and simply relied on real words, but I’m a Pascal guy so…
I hate when closing statements don’t line up – and in this case it’s inconsistent with the use of curly braces… how is this:
switch ($expr) {
case 0:
echo 'First case, with a break';
break;
case 1:
echo 'Second case, which falls through';
// no break
case 2:
case 3:
case 4:
echo 'Third case, return instead of break';
return;
default:
echo 'Default case';
break;
}
… easy to follow since they all look like drop-throughs? how are the placements of break and return consistent with the use of {} – simple, they aren’t. Consistency certainly is something they never even considered when you look at idiocy like this:
class Foo extends Bar implements FooInterface
{
public function sampleFunction($a, $b = null)
{
if ($a === $b) {
bar();
} elseif ($a > $b) {
$foo->bar($arg1);
} else {
BazClass::bar($arg2, $arg3);
}
}
final public static function bar()
{
// method body
}
}
Opening brace on same line for operation constructs, but not for classes, methods or functions? A LITTLE CONSISTENCY GUYS!!! Pick a style, not your nose.
That’s my problem with a lot of these types of specs; you can see the design by committee everywhere since there are ZERO clear simple consistent rules. Every time they come to something with another name using the same elements, poof, entirely different way of formatting it.
… and if every case gets a special rule, sorry, that’s not standardization, easy to use, easy to follow, or on the whole worth even TRYING to deal with.
Then there’s all the namespace stuff. I still say if you need that complex a namespace you’ve overthought the solution to your problems – it’s a train wreck of needlessly complex rubbish. In particular, that the namespace uses different delimiters on the filesystem vs. in the program – or even that the program should give a flying purple fish after the code is loaded if said code is actually written properly… I really don’t get why people think that mess is warranted in ANYTHING… but then, I don’t sleaze together off the shelf libraries any-old-way, and disagree with how 99.99% of them work. (probably 100%, I’m just leaving the possibility of there being one that doesn’t SUCK). Hell, it bugs me how PHP passes local scope to includes; there really needs to be a language level include that says do NOT pass scope – that way I’m not doing dumbass functions like:
function safeRequire($file) {
/*
This is REALLY stupid, but PHP passes local scope to includes -- meaning
any local variables, even our protected/privates may as well be superglobals
when you include/require. Wrapping require in a function breaks that scope.
Remind me to beat the tar out of whoever thought that was a good idea.
*/
require_once($file);
}
But then, I only ever use require_once… I see no legitimate reason for include or non-once to be used since all libraries (includes) should have their code wrapped in classes, methods or functions – that way you can’t blind call them.
Then there’s the “let’s make EVERYTHING use a different naming convention” – which sounds all rosy since if you know the rules you can at a glance tell a class from a method from a function – but it’s also pointlessly difficult to keep track of, and to be frank, if you can’t keep track of:
class myClass {
function method() {
}
}
$class=new myClass;
$class->method();
… in that the word class says it’s a class, saying new means it’s a class, using -> means it’s a variable of type class followed by a property or method, () means it’s a method, lacking it means property… then going to goofy inconsistent naming schemes is NOT going to help you! Again, are people punctuation blind or something?
But too keep it in perspective, what do I know? I think the acid trip of color syntax highlighting is an illegible mess and tabbed editors are a step backwards in functionality!
Still, I find said proposed “standard” to be inconsistent, nonsensical, and almost seeming to be put together willy-nilly. Some parts seem needlessly complex over something simple, some parts seem to be micromanagement of things like directory structures – and not in a good way… and some of it (like brackets and braces) just seems like they want everything to be intentionally random and different to no real advantage.
- my own way of formatting because as the code got more complex it became 
) I prefer to have everything in the single file.
