Fair enough, would have given people more credit for updating with the times / languages though!
| SitePoint Sponsor |
I like to think that it's a testament to the power of style guides. They stick around because nothing has significantly come along to replace it.Originally Posted by Stormrider
Strunk & White's book of the Elements of Style retains its influence over the English Language for similar reasons.
Programming Group Advisor
Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
Car is to Carpet as Java is to JavaScript
FYI, My style is directly from Sun's Java Coding Style Guide
I find this to be the most organized, consistent, and efficient way to program in C-style syntax.
Look into it. I think you'll like it!!
This is one of the problems that I disagree with. Languages have their own issues and difficulties to deal with, so even if they are superficially similar, one coding style may not be as appropriate as another.
It can be tempting to at times, because then you don't have to learn different sets of coding styles for different languages, but those differences tend to be there for good reasons.
Use a Java-specific style guide for when writing Java, and a separate PHP-specific style guide for when writing PHP.
The only time I would use Sun's Java Coding Style Guide for writing PHP is if I'm entering a position at a company that for some strange reason demands you code PHP according to Java's style guide.
Programming Group Advisor
Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
Car is to Carpet as Java is to JavaScript
What specifically do you have a problem with regarding Java-style code for PHP? Camel-case naming? JavaDoc commenting (which happens to be identical to PHPDoc commenting)? Other than naming conventions, nothing is very different in Java-style coding...
That's like wearing someone else's underwear. Sure it can work, but you're better off using ones that belong to you.
Programming Group Advisor
Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
Car is to Carpet as Java is to JavaScript
I find this work best for me:
Monday: I use the PEAR system.
Tuesday: I use the ZF syntax, Monday got me in the groove, but by Tuesday I can rock with ZF.
Wednesday; I usually drink too much - so revert to Mondays' system.
Thursday: classic C syntax ( with tab set to 2 spaces) it is esoteric but comforting.
Friday: I use Sun's Java coding style.
Saturday: I drink so much that I neither care nor bother.
Sunday: move all the next weeks' coding systems up by one.
This might seem confusing but in effect it is very simple, by looking at the various phases of the moon and by holding up to the moon a laser print-out of my code for the corresponding day I can very easily tell how effective my code has been, then I touch some wood, recite the "Hail Mary" three times, backwards, and the answer appears - but of course not the reason for the code.
*sigh*
When all else fails I write a new thread on sitepoint, and try to desperately divert attention away from my vacid inability to concentrate on problem solving.
I mean, **ck, we've all done it!
Not bad, Cups. Reminds me of my approach to all this...
[Leans back in his office chair reminiscing of some distant memory...]
After spinning around 7 times counter-clockwise in my office, jumping up and down on my left foot while holding my right foot behind my body using my left hand, I type each character of each function name and each variable name upon each spinning revolution while singing "American Pie" backwards using the timbre one would normally hear in Led Zepelin's "Immigrant Song", and would you believe that I have created an entire CMS platform using 1 incredible line of code complete with MySQL transactions, session handling, registration, module support...!?
One line infrastructure, baby.
Well, having been a Java coder for years before moving to PHP, lower-case-underscore naming always felt that way for me... awkward and ridiculous. Lower-case-underscore is (in my mind) reserved for DB objects, URIs, XML ids, and other meta-data attributes... not used anywhere else in coding... it just feels wrong for variable and function names, because it breaks the barrier between meta-data and code - a clear separation that I have in my mind. I guess that's why I stuck with Java naming conventions. I find them way prettier. Actually, I even used camel-case back in the day when I was a MS programmer. It's just so pretty.
I like using the space bar and enter key on my keyboard A LOT. I mean why not? Whitespace won't hamper the code plus it can help space things out and make it a little more readable. Long lines of code are a bane. (I also try to keep things under 80 characters long relative to indentation. Indentation itself is 2 spaces.)
Just a sample code ref:
Code PHP:<?php namespace [Vendor]\[Project]\[Package]; /** * Short Description... * * Long Description can span many lines and contain examples or any other * details. Most cases this portion will be blank. * * @copyright [year] [Author|Company] * @license [url]http://[vendor]/legal/oss/license[/url] BSD License * @license [url]http://[vendor]/legal/pro/license[/url] Proprietary License * @link [url]http://[project][/url].[vendor]/api/[package]/[component] * * @category [project] * @package [package] * @version $Id$ */ # 80 char range #------------------------------------------------------------------------------- use Some\OtherA\Name\Space as AliasA, Some\OtherB\Name\Space as AliasB; /** * Description and example of the inner workings of this compnent. * * @category [project] * @package [package] */ class ComponentCamelCase extends AliasA implements AliasB { const CONST_ONE = 1, CONST_TWO = 2, CONST_THREE = 3; protected // Always protected! $varOne = 'default', $varTwo = 'default', $varThree = 'default'; #------------------------------------------------------------------------------- /** * Short Description... * * Long Description... * * @param string $a description... * @param integer $b description... * * @return void * @throws UnknownException, KnownException */ public function camelCase ( $a, $b ) { if ( expression ) { // multi-line action... // lots of code... } elseif ( expression ) { // more multi-line actions... // more lots of code... } else { // fallback action... // more lots of code... } // or, for single line if ( expression ) // action... // or put it under... $arr = array( 'key' => 'value' ); $arr['key'] or $arr[ $key ]; # mixed ( string $a, mixed $b ) + array $global # throw UnknownException, KnownException $call = function ( $a, $b ) use ( $global ) { // action... }; return $this; // Always return $this unless it must return something else. } }
logic, very nice. You're using 5.3 already? How do you like it?
I go a step further... I use hyphens for class attributes (e.,g. .class-name) and underscores for id attributes (e.g. #page_header) lol. I'm a little ocd.
PS - Regarding indentation... why not just indent with tabs and let the individual developer decide what that means in their IDE (most IDEs allow you to configure tabs as 2 spaces, 4 spaces, 5 spaces, etc)? I find that tabs are sadly underused by developers who want to control not only how THEY indent, but how YOU indent. When I find a spaced-indentation on a file, the first thing i do is a Find-Replace for tabs.
One of the problems that are immediately faced is that as the tab size changes, the code indenting becomes inconsistent.
for example:
It looks fine with a tabstop of 4, but with a tabstop of 8, the two tabs in the gap suddenly become:Code:$car = new Vehicle('car'); $boat = new Vehicle('boat'); $motorcycle = new Vehicle('motorcycle');
So what do you do? Demand that tab stops all be the same size, such as 4 spaces? Where then is the benefit of tabs being able to represent multiple numbers of spaces?Code:$car = new Vehicle('car'); $boat = new Vehicle('boat'); $motorcycle = new Vehicle('motorcycle');
Smarter editors that use spaces when you tab seem to be more common-place these days.
Last edited by paul_wilkins; Mar 17, 2011 at 15:53.
Programming Group Advisor
Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
Car is to Carpet as Java is to JavaScript
Depends how lazy Im feeling and on how complex the script is. But I prefer A to B
Same with commenting the code, if its a basic script then very little comment, if theres a lot going on then Ill comment more than I code, I dont wanna spend a day in 2 years time trying to figure out what the hell I did.
A Little Knowledge Is A Very Dangerous Thing.......
That Makes Me A Lethal Weapon !!!!!!!!
Contract PHP Programming
I've been using 5.3 before it even was released. It is still PHP there is nothing dramatically different other then a few additions. It is not like upgrading to a new or different Operating System.
Right, but how stable is it? I'm always wary about upgrading server software in a production environment... and 1 year is not "quite a long time" in relative terms... if there's a security hole, and you're building PCI compliant apps, you're screwed.
There's a reason managed servers all come pre-installed with 5.2 still...
If there is a security hole it is probably (more then likely) in the previous version as well.
You also say that like the previous version has no (or would not have) security holes itself.
And it is as stable as PHP has ever been, take it as you will.
Off Topic:
PHP 5.3 has been out nearly 2 years, not one. Further, PHP 5.2.x has had it's final release put out and will not receive new updates unless they are critical security flaws.
PHP 5.4 is on the horizon - it MIGHT be out this fall, but predicting PHP releases is almost as bad as picking lottery numbers.
Off Topic:
Package managers are so slow to get the latest updates for PHP in. Really annoys me. Have to install apache and PHP from source to get it to work with 5.3, but at least it's done now!
Two years is easily enough time to find out if there are any major show stoppers preventing you from upgrading. I see no reason not to really.
Sounds good to me... thanks!
Posting Permissions
Reply With Quote
Bookmarks