Current and former colleagues of mine, will attest to my intense hatred of poorly written code and by poorly written code I mean code that is hard to follow.
In a bid to make my PHP code even more readable I’m dumping the curly brackets traditionally used with control structures (e.g. ifs, fors, switches) in favour of the colons and semi-colons of PHP’s alternative alternative syntax for control structures.
PHP’s traditional syntax for control structures – with curly brackets {}
<?php// If statementif(1==1){doSomething();}else if(1>1){doSomethingElse();}else{doSomethingSpecial();}// For loopfor($i = 1; $i < 5; $i++){echo $i;}?>
Upon quick glance the usage of curly brackets it is obvious which bracket belongs to which control but it soon becomes more difficult to read when functions/methods are thrown into the mix and lots of nested controls exist.
Too many curly brackets {{{{{{}}}}}}
<?php// Nested if's and foreach's statement inside a functionfunction myFunction(){if($trees == 'green'){if($trees > $children){foreach($array as $key => $value){if($trees != 'dead'){doSomething();}}}else{doSomethingElse();}}else{doSomethingSpecial();}}?>
The example above, shows it becoming a little more difficult to follow which bracket refer to which control. The very fact that my method of displaying code samples (codeviewer) removes indentation/tabs from the code makes this even ore evident.
PHP ‘s alternative alternative syntax for control structures :;
<?php// If statementif(1==1):doSomething();elseif(1 > 1):doSomethingElse();else:doSomethingSpecial();endif;// for loopfor($i = 1; $i < 5; $i++):echo $i;endfor;// nested if statements inside a functionfunction myFunction(){if($trees == 'green'):if($trees > $children):doSomething();else:doSomethingElse();endif;else:doSomethingSpecial();endif;}?>
For me, I find this so much easier to read. Replacing the last curly bracket (}) is a statement of the following endif;, endfor;, endswitch; etc. This means there less confusion as to what things are referring to.
Summary
It is imperative to write code that makes sense for other developers in your team or for the developers will inherit your code.
I find this alternative control structure much easier to read but what do you think? Do you find it easier or harder to read?
Has your blogging software removed all the tabs and indenting? It still looks hard to read to me.
@stuart: yes it has but I’ve just gone in and updated the CSS, so it should be indented properly if you F5 the site.
Curly braces are not especially hard to read if you have experience in any C-style language (such as PHP). Most editors will show you a matching brace (but will not show you a matching endfor/endif), so it depends on the experience and viewpoints of your fellow devs and which tools you have in place to support development.
I do agree that the alternate syntax is slightly easier to track when using PHP embedded in large HTML files ( (we use them here for views/templates only), but I’d be a little wary of forcing other developers (that you may never talk to) to maintain such an uncommon coding style for classes and other files. Any personal style which could be referenced after your employment with the company as ‘Phil had a habit of…’ is something I’d think long and hard before enforcing adoption.
Plus you’re still tied into using curly braces for your classes, methods, functions, third party code, etc, so I’d consider it muddying the syntax waters.
@Mark: I see your point. If anything that the fact that the curly brackets are also used for classes, methods et al means it can get even more confusing.
I found myself, commenting all my curly brackets like so:
} // end ifor} // end for loopjust to be able to remember what they belonged to, so altering the syntax feels like natural progress to me.I share your hatred of poorly written code. However, I agree with Marks comment (excellent comment by the way ;)). The alternative syntax is very useful for your views/templates but for other stuff I would be tempted to keep the curly braces. One of the main reasons is bracket matching. I know its a small feature of code editors, but what a helpful little feature it is.
You still run into the same problem if you start nesting lots of functions using this alternative syntax. Maybe not as soon as with braces, but not much later. I do like these syntaxes (correct plural?) but I prefer to use comments to label my closing braces, just like how many people label closing tags in html. Usually a comment like ” } //if (condition) ” is enough to jog my memory and help me figure out which opening brace a particular closing one corresponds to.
Like I said though, I do like the ability to use endif, reminds me of bash :)
@Ian: which editors do you use which do support bracket matching and not the alternative syntax matching. As I only use a combo of either DreamWeaver/Coda which (correct me if I’m wrong) don’t support either syntax but I’ve just downloaded Textmate in the last 5 minutes and that seems to support both.
Coda definitely has brace matching (it ‘pings’ the matching brace when you move your caret over it). Doesn’t look like Dreamweaver does, Textmate does also (changes background colour on braces when caret’ing across the matching brace, but not on alt. syntax). Doesnt look like any of them can highlight the endx; syntax though.
Forgot to clarify earlier that the reason I use alternative syntax in views/templates is that, when I have a large number of documents open, it makes it very clear which ones are ‘templates’ and which ones should actually do the work (acts as a quick visual hook per file to the context of development).
@Mark James: I see, I’ve just checked in Coda and it does indeed do what you say. Double-clicking the bracket actually highlights the entire block. Which is very useful. Textmate will collapse an entire block if you press F1 with both syntax styles.
I use Textpad (windows only – but is very good) ctrl-m on a bracket will match it up. I often use smarty for templates but if only using php then the short hand syntax comes in very useful.
I prefer to use brackets. IMO it makes it a lot easier to read (and maintain) code.