With all of the frameworks making their way around the PHP community, it's interesting to see different developers' takes on judging which is the best for their needs. In this new post to his blog Volker Dusch takes the opposite stance - he hates talking about frameworks.

I just hate talking about frameworks! But as it seems not many people share that feeling so this is an attempt to write a rather short and linkable post on how i approach a new framework and by what standards i judge it. [...] I'm not going to call any names in this post so no need to grab your pitchforks. (For some reason people seem to get really upset when you tell them you don't like the framework the use)

He asks himself a few questions like "can I still write code to my standards" and "how many 'positive adjectives' are used in the description" (inversely related to the quality of the project in his experience). He also talks about one of his other big requirements - being able to actually write unit tests for his code (i.e. the framework must make things testable).

Volker Dusch has a suggestion for all of the PHP projects (or, really Open Source projects in general) that can help keep things cleaner in your codebase and make for simpler times when merging contributions - including your coding standard along with the rest of your project.

Let me elaborate on [an important] point: Contribution. Most developers i know care about producing good code, especially then they are contributing to an open source project! Those people will respect your coding standard, naming scheme and every thing else that they can check for before sending you all patch/pull request. So try to make that part easy.

He talks about doing things the hard way - reformatting everything by hand each time someone contributes - or the easier way of enforcing the coding standard as a part of the contribution flow. He mentions PHP_CodeSniffer and the PHP Mess Detector as a part of a Jenkins installation (easily built from this handy project).

On the Mayflower blog today there's a new tutorial posted about creating coding standard "sniffs" for the PHP_CodeSniffer tool. A "sniff" is what defines the rules for your coding standards to follow (like "curly braces after function definitions should be on the next line" kinds of things).

In some cases the pre-installed coding standards like PEAR or Zend might not be sufficient for our current project or we want to deviate. This is the moment when we want to be able to create a custom one that fits our special needs. In this article I want to share my first experiences with you about how to create a custom coding standard for PHP_CodeSniffer.

They get into the details of what a "sniff" is and shows where they belong in the current structure of your PEAR install. There's an example of how to run the command line tool and how to create your own structure for your own custom sniffs. Their first example sniff checks to ensure that the first letter of a class is in uppercase.

On the Nefarious Designs blog today there's a new post looking at something that can be a key in the strategy of a development group - creating a coding standard.

In my time as a web developer, I have been involved in the definition, implementation, and maintenance of several different coding standards, across various web-based languages. In my experience, this process is not as straightforward as it first seems, and can lead to a great deal of headaches if not handled in a very specific manner.

He talks about why a coding standard is even important and some of the first steps you and your team can take towards creating them. He breaks it up into a few different sections:

• Comments
• Naming conventions
• Style (ex. tabs versus spaces)
• Already accepted standards
• Expressions
• Concerns over file size

Mashable has posted the third part of their "PHP experts" series with a look at what the eight people on their panel think are some of the pros and cons about developing with PHP.

In recent posts, our "PHP masters" gave helpful hints for beginners as well as some pointers for intermediate and advanced coders. For the last post in this series, we've turned to the same experts with some more general questions: What makes PHP a good language? What are some of PHP's drawbacks? And what are the best apps or cleverest hacks you've seen made with and/or for PHP?

Some of the reasons the panels gave were some common issues you hear about with PHP every day - how easy the language makes "spaghetti coding", the low barrier to entry (both good and bad), a problem with copy and pasting and - a very good thing - the documentation the project provides. Disclaimer: I was a member of the panel.

Developing applications has become simpler and simpler these days and the multitude of IDEs out there can help you keep all of your files organized and linked together so you know everything is in its place. There's one thing that only a handful out there can do, though - enforce coding standards. Thankfully, there's a tool that can help you keep your code following down the right path and PHPBuilder.com has a new tutorial about using it - PHP_CodeSniffer.

Although defined according to formal grammar and syntax, programming languages -- like their spoken counterparts -- often leave their users with a great deal of leeway for creative expression. [...] It can even be singularly counterproductive if you do not maintain stylistic consistency across projects, as you'll need to continuously re-acclimate to differing syntactical variations.

The PHP_CodeSniffer tool runs your code through a validation process and checks its structure against a coding standard (like the PEAR standard) and ensure it's formatted correctly. The tutorial shows you how to use the "phpcs" executable to test PHP, Javascript and CSSS files (using the Squiz standard).

In a new post to his blog Leszek Stachowski wonders about a coding convention that's still widely used when it comes to private methods in a class - the underscore prefix.

The question which comes instantly to my mind is: why? Is there any reason why this convention should be kept when PHP object oriented programming has gone a long way since PHP 4 (when there was no access modifiers and such underscore was the only fast way to distinguish public from, hmm, not public methods and properties) ? Are, for instance (as one of major OOP languages), Java coding standards pushing towards such naming convention? No!

He, like many other developers, are pushing to drop this kind of convention as an outdated reminder of the PHP4 days when "private" didn't exist in the language. Scope modifiers have done away with the need for that underscore completely.

On SitePoint.com there's an interesting opinion piece on one of the bigger debates in the web development world - should designers know how to write code, even if it's just a little?

This debate has been raging on SitePoint for some time. The issue was raised by Elliot Jay Stocks following a simple tweet: "Honestly, I'm shocked that in 2010 I'm still coming across '˜web designers' who can't code their own designs. No excuse."

This, of course, sparked a whole host of other opinions from the SitePoint readers and they've gathered them together and summarized the "for" and "against" topics from there. Those on the pro-coding side suggest that not only does it give them some appreciation for what the developers do for the designers but it also can make them a better, more flexible asset down the line. The those on the con-coding side suggest that designer time is precious and should be devoted to the usability of the site. They also note that you don't "need to be a plumber" to know how to get a working site together - each member needs to do their job.

Be sure to check out the comments for some other great thoughts from the community.

On the Smashing Magazine site today there's a new post with an interesting perspective on how writing code (regardless of the language) is similar to writing poetry - a more human spin on something generally thought of as logical and restrictive.

That's an interesting metaphor. Recently, I've written about the different languages used by designers and developers, and also about the relationship between these coding languages and proper human language (specifically, English). As someone who graduated from university with a degree in English Literature and came to Web design in a roundabout way, this kind of thinking has always interested me.

He starts at a high level looking at a superficial similarity in how they're structured on the page and how they can use just the things they need to get their point across. He also talks about the bad code/bad poetry similarities and how purpose, meaning and structure all come into play.

Be sure to check out the great comments for more thoughts on the subject.

In a new post to his blog Klaus Graefensteiner takes a look at a quick way you can enforce your set of coding standards right inside of the Eclipse IDE with the PDT extension installed. It's not the easiest thing to do, but if you have a well-defined coding standard and know you'll be enforcing it strongly, this might be the way to go.

I recently came across a nice collection of coding standards that the developers at Gallery2.org are using. I especially liked the summary of settings for Eclipse PDT. I applied them to my Eclipse PDT development environment, took some screenshots and put this article together for my personal reference:

Settings he changes include some of the general editor settings (like tab width and margins) as well as PHP and source control specific settings to remove extensions the IDE doesn't need to worry about. He also mentions the "Code Templates" feature that allow you to get more specific and define the standards at the code level, not just the editor.