By Harry Fuecks

PHP Coding Standards – do you care?

By Harry Fuecks

Over at WACT the question of coding standards has raised it’s (ugly?) head. There’s now this page on the WIKI linking to more or less every PHP coding standards document that’s ever made it’s way online (feel free to add more).

By “coding standards” we’re talking whether you use tabs or spaces for indention, whether you name functions likeThis(), LikeThis() or like_this().

Now for some people this is really important. Risking flames, I think it’s just “nice to have”.

If you’re collaborating in a team, so long as you display basic “code hygene”, that’s enough. With reasonably experienced developers, conventions on naming class methods and so on will likely evolve without even needing to discuss them.

What’s more, think the subject is largely a distraction from more important issues. Try asking the next Java developer you meet what the word “standards” means to them… Having clearly defined APIs for things like Iterators is far more important, IMO.

  • Perhaps we need a universal syntax “driver”.

    Some people like ADODB. Some people like pure MySQL calls. WACT supports both. Why not support both types of syntax?

    (PHP5 Syntax)

    class template {
    private $functions;
    template {
    $this->functions = array {
    "get", "post", "findMatch"
    function __call($name, $arguments) {
    //Some regex / matching yet to be devised...
    call_user_func(array($this, $function), $arguments);

    Once they realize the overhead their differences will cost them, they’ll probably learn to like the style the designers picked, and get over it. What coding without a little variety now and again? (callUser_FuncWithout__ANYPARAMETERS()) :D

  • I think you hit the nail on the head when you said, “If you’re collaborating in a team, so long as you display basic ‘code hygene’, that’s enough.”

    There’s no need for every PHP developer to stick to the exact same coding standard–what’s important is that all of the developers working on Project X stick to _some_ standard. It makes it a whole lot easier to communicate through the code if you know what to expect.

  • Dispite what peoples impression of Microsoft is, I think that they have their Naming Guidelines spot on.

    Capitalization Styles

    Pascal case

    The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters. For example:

    Camel case

    The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. For example:


    All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters. For example:



    To avoid confusion and guarantee cross-language interoperation, follow these rules regarding the use of abbreviations:

    Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.
    Do not use acronyms that are not generally accepted in the computing field.
    Where appropriate, use well-known acronyms to replace lengthy phrase names. For example, use UI for User Interface and OLAP for On-line Analytical Processing.
    When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.
    Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.

    Class Naming Guidelines

    The following rules outline the guidelines for naming classes:

    Use a noun or noun phrase to name a class.
    Use Pascal case.
    Use abbreviations sparingly.
    Do not use a type prefix, such as C for class, on a class name. For example, use the class name FileStream rather than CFileStream.
    Do not use the underscore character (_).
    Occasionally, it is necessary to provide a class name that begins with the letter I, even though the class is not an interface. This is appropriate as long as I is the first letter of an entire word that is a part of the class name. For example, the class name IdentityStore is appropriate.
    Where appropriate, use a compound word to name a derived class. The second part of the derived class’s name should be the name of the base class. For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception. Use reasonable judgment in applying this rule. For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.

    Interface Naming Guidelines (PHP 5)

    The following rules outline the naming guidelines for interfaces:

    Name interfaces with nouns or noun phrases, or adjectives that describe behavior. For example, the interface name IComponent uses a descriptive noun. The interface name ICustomAttributeProvider uses a noun phrase. The name IPersistable uses an adjective.
    Use Pascal case.
    Use abbreviations sparingly.
    Prefix interface names with the letter I, to indicate that the type is an interface.
    Use similar names when you define a class/interface pair where the class is a standard implementation of the interface. The names should differ only by the letter I prefix on the interface name.
    Do not use the underscore character (_).
    The following are examples of correctly named interfaces.

    Static Field Naming Guidelines

    The following rules outline the naming guidelines for static fields:

    Use nouns, noun phrases, or abbreviations of nouns to name static fields.
    Use Pascal case.
    Do not use a Hungarian notation prefix on static field names.
    It is recommended that you use static properties instead of public static fields whenever possible.

    Parameter Naming Guidelines

    Use camel case for parameter names.
    Use descriptive parameter names. Parameter names should be descriptive enough that the name of the parameter and its type can be used to determine its meaning in most scenarios. For example, visual design tools that provide context sensitive help display method parameters to the developer as they type. The parameter names should be descriptive enough in this scenario to allow the developer to supply the correct parameters.
    Use names that describe a parameter’s meaning rather than names that describe a parameter’s type. Development tools should provide meaningful information about a parameter’s type. Therefore, a parameter’s name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.
    Do not use reserved parameters. Reserved parameters are private parameters that might be exposed in a future version if they are needed. Instead, if more data is needed in a future version of your class library, add a new overload for a method.
    Do not prefix parameter names with Hungarian type notation.

    Method Naming Guidelines

    The following rules outline the naming guidelines for methods:

    Use verbs or verb phrases to name methods.
    Use Pascal case.

    Property Naming Guidelines

    The following rules outline the naming guidelines for properties:

    Use a noun or noun phrase to name properties.
    Use Pascal case.
    Do not use Hungarian notation.

  • I think perhaps what is at issue here is the question: How painful is refactoring?

    If you are comfortable hitting all of your code and making changes to function or class names, then it is easier to operate with a looser style. If this is painful (say where you have publically released code and this would break the API) then having the standard up front is probably more desireable.

    WACT is in a state where is certainly can still easily change, so the question would perhaps be: Do you want the style to just emerge from the work, or do you want to pick something and work towards implementing that style?

  • seratonin

    You bring up an interesting point. Is is “so hard” to follow coding standards? Does it make the development *less* efficient to following coding standards? I think standards are extremely important if you are working in a team and you have short cycle times. In a collaborative environment, it is much easier to look at other’s code if it is all the same style. Iterative and Agile development methods (e.g. eXtreme programming) advocate coding standards for a reason. Then again, these methodologies emphasize collaboration, pair programming, code reviews, etc…


  • There is truth in everything that has been said. Sometimes you need it, sometimes you don’t.

    There is a possibility that another webmaster and I may merge some of our operations, code, data etc.

    A little hygene list will go a long way to my understanding his code and him being able to read mine.

    Thanks to all

  • dragondev

    I write code in a variety of languages. My formal training is that of a computational physicist. Conventions and standards are concepts that I am very familiar with. When it comes to writing code though, I think that a few simple practices are all that are required. First, the programmer should adopt a style and stick with it. Names of functions, variables and objects should be descriptive without being overly long. Use indentation to make the code readable. Write the code so that when you have to dive back in 6 months later you will be able to quickly make sense of what you were thinking at the time. To me this is just common sense and shouldn’t need to be written into a standard.

    There is one final practice that is far too often ignored by most, myself included when I am trying to meet a deadline, that is clear, concise and effective documentation and commenting. It doesn’t matter if developer A is using camel back for objects and capitalizing the first letter of the words in a concactenated string for functions and developer B is doing the opposite when a few lines of text tells you everything that you need to know about what you are looking at.

    The only time that using different styles can pose some real concern is in a team effort. In those cases the style should be agreed upon by the team. Even then the chosen style should be one that everyone is comfortable with and not necessarily one that is imposed by some “higher power”.

  • phoques

    What about the poor guy who gets hired to go through all the non-standardized code of previous developers? Just a thought…

  • I’m with you on the “nice to have” viewpoint. It does help if people in a team code the same way because code becomes much more readable to one another. Beyond that… who cares?

    One development that I’ve seen in Microsoft Visual Studio that would be good in Macromedia Dreamweaver is the way that it auto-indents when you hit Return at the end of a line or when you put a close brace “}”. That way, you don’t even have to think about some of these issues.

  • With reference to the above post, the ideal situation would be to allow the editor or enviroment, to handle the initial style and standard layout of code. Which would resolve the individuals taste for their style of coding. I have considered numerous times, developing my own editor in C#, which I can extend and control myself, but it seems to be reinventing the wheel.

  • I think, as PHP is similiar to Java in some things, so it’s sensible to inherits its coding standarts

    functionName ();
    $instanceName->methodName ();
    and etc.

  • ZangBunny

    One point for coding standards comes up when you work with CVS or any kind of version control, namely minizing diffs.

    When everyone who works on a piece of code uses the same rules for indentation, placement of braces etc., the diffs between tho revisions will show only the actual changes and leave out the formatting chaff.

    (The most important issue in this is line endings and tabs-vs-spaces-indentation. If you don’t agree on them, *every* line will be in the diff, very effectively hiding the real changes.

  • In my opinion, standards are never a

Get the latest in Front-end, once a week, for free.