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).

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).

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.

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

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.

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).

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.

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.

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.

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.