Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy. This forum is not for asking programming related questions.
Maybe someone here can figure this out. Why do Zend specify that classes and functions should have the opening brace on a seperate line, and if blocks and switch case blocks have the brace on the same line? Eg
I've always done it the "Zend way". It's nice to be able to quickly distinguish between business logic and the main method to which it belongs, especially when you're dealing with large classes. A normal if block will only consume a few lines, and I feel like the extra brace just takes up space unnecessarily. For method declarations, which may encapsulate hundreds of lines, it's much easier to spot when you're scrolling up a 500 line file at coffee-induced speeds trying to find what the argument variable names are. I guess it's mostly a matter of taste, though.
It's a small compromise between two competing styles. The PEAR conventions are basically the "One True Brace" style. The main advantage is to fit as much code as possible into a screen. You'll notice it's always accompanied by an "80 character" line limit - the width of a typical terminal display... This was amended later to exclude class and method declarations - far more important to segregate them visually!
The other is BSD/Allman - all braces occupy a single line. The advantage here is to improve readability, and further visually separate blocks of code. Unfortunately it's rarely applied in PHP - every time it's debated someone turns up who actually seems to use a limited console editor over and IDE or wrapping editor where screen space is limited.
Of course the debate is moot in a braceless language - the fun argument there is over camelcasing .
I use the BSD/Allman where possible - the other is reserved for only a few cases where coding standards like PEAR or ZF require it. At the end of the day it's a preference, and is usually best to apply whichever you want consistently in a project. For those exceptions I find a find/replace works pretty well, or having two autocomplete settings depending on the standard.
Well, the reason I ask is because I can see myself moving on from my current job sometime in the not too distant future, so I'm looking for a documented standard coding style I can shift over too instead of "what Onion likes". Just something nice to show in code samples should anyone ask for them. I was reading the documentation and wondered why it might be the case.
It's not a bad standard - it's consistent, and been in use in PHP for years. Adopting it is as easy as configuring your IDE for it (if needed) and banging away at your code as usual. If you really really like consistency there's a PEAR analyser which checks PHP files for adherence to the PEAR standard.
onion2k wrote:Well, the reason I ask is because I can see myself moving on from my current job sometime in the not too distant future, so I'm looking for a documented standard coding style I can shift over too instead of "what Onion likes". Just something nice to show in code samples should anyone ask for them. I was reading the documentation and wondered why it might be the case.
Ask in your interview or when you start (when/if you get one) if they have a coding standard.
This may seem obvious. If there is legacy code, follow the coding style in that code. Having multiple styles in different file sounds terrible, but having different styles in the same file is horrible to read. The same should apply to code usage, e.g. some code will prefer to use one set way of doing things, some others. Consistency is a good thing.
You can alway buy a widescreen and turn it sideway to give you more screen length.
Legacy code can be updated. When I came into my role as the web developer for my company, the first thing I did was establish standards for PHP, CSS and HTML. Then I developed a standard for code control, then code implementation. All legacy code was to updated to the new standard every time it was touched.
Yes, there is some old code style around, but as soon as it gets opened again, it is getting updated to the standard.
Legacy code rarely has a standard anyway . Most of the legacy PHP stuff I've seen tends just to be a messy clump. Cleaning it up to a standard is almost a necessity before doing anything else.
I like the Zend braces because you can easily tell from a glance what is a function or class and what is a control block. So for me its more than a compromise its better than either on their own.