By Hari K T

PSR-1 and PSR-2 to be Approved as Standards

By Hari K T

I hope you all know about the PHP Framework Interoperability Group. The group proposes standards (PSRs) that developers can adhere to in order to make it easier to use their different libraries and frameworks together. The first proposal was PSR-0 for autoloading class definitions and was a huge success. Recently, the group found it important to address coding standards that should be used in different projects. This proposal was first proposed by Klaus Silveira and modified heavily by Paul M Jones after being discussed heavily done in the group’s mailing list.

Of course there were a lot of differences in opinion and the group members fought in a friendly manner to bring about the PSR-1 and PSR-2 proposals. They initially started out as one proposal but the initial round of voting didn’t yield a majority in favor. Participants did however see merit in various requirements the decision was made to split it into 2 proposals — one for mandatory interoperability and one for suggested style.

The voting on PSR-1 and PSR-2 has begun, and they will only be accepted as standards if they get a majority of votes. There are 20 members, and both PSR-1 and PSR-2 have over 11 votes meaning they will soon be accepted as standards. The proposals are:

I appreciate Jones for his time and dedication as a leader to make the PSR. This will help to bring a wonderful future for the PHP community as a whole.

There is more good news in that PSR-1 and PSR-2 can be enforced with PHP-CS-Fixer. The goal is to automate the fixing of most issues, and the tool knows how to fix issues for the coding standards defined in the PSR-1 and PSR-2 documents. Thank you Fabien Potencier for your efforts on the sniffer; you did a great job.

Image via Fotolia

  • Hari,
    Thanks for the update. I’m not always keen for committees, however when professional collaboration & discussion yield results that move the community as a whole forward in more defined and organised ways, then i’m right behind it. A plus is the code sniffer that helps us implement it in our regular development work.
    It’s good news.

  • Ignatius Teo

    I’m appalled that I MUST now indent 4 spaces instead of a single tab…

    • Sean

      I agree.

      There were 22 people were involved in voting on fundamental coding standards for a community of thousands. Why not open a survey to the community rather than restricting it?

      • Hi Thanks to all for your comments.

        First of all, there are no restrictions for people who are following their own coding standards. So why do you guys want to move to .NET :-) .

        “There were 22 people were involved in voting on fundamental coding standards for a community of thousands.”

        Let me try to correct this. At present there is only 20 leaders and they are the core contributors of popular open-source products (frameworks or cms) who are trying to bring about better interoperability. You can also become a voting member if you have such a project. See
        If the project/leader mandates to follow certain standards, everyone follows it ( eg: Zend , Symfony , Pear , Aura) Every one has their standard, and if you are contributing to a project you are forced to follow the standard. So why not a single standard between them all? This means its clear the leader has the last thought/decision to move forward, and not its users.

        “Why not open a survey to the community rather than restricting it?”

        Indeed all are taken from the survey, debates and stuff :-). It took months to get to this point. See .

        About the group: It’s always open to suggestion from non-voting members also.

        Space vs Tabs: See Tyler Sommer’s comments. Also have a look into the article

        Hope this answer some questions/concerns of people who are new to PSR. I welcome you to join and be part of the open-source community.


        • Sean

          Thanks for replying.

          I know one person mentioned going to .NET – certainly not me :-)

          I am totally in favour of standardisation and yes we follow code standards in the projects I work on.

          Fair enough having group members etc but I don’t see any reason why the survey couldn’t have been opened up to any PHP developer and promoted to get as many votes as possible. Getting a larger opinion base would give more credibility and acceptance for the results.

          • The main objective of standardization is interoperability. Code styles may be personal matters, but when standardized they are more predictable to read both by humans and by applications that will read this code for something. On the matter of an open poll … I strongly disagree. The are several reasons to disagree, but I cite two main ones: (1) is not always what is more used is better (2) a more limited and quality discussion is better than a ‘global discussion’ does not decide anything and always dies in a deadlock.

    • Tyler Sommer

      Why is this so upsetting? Every editor I’ve ever used, other than maybe Notepad or TextEdit, has an option to seamlessly change any tab into X number of spaces. It’s not like you have to press the spacebar four times… Why are people so upset about this specific rule?

    • Chris Emerson

      Tabs are for laying out tables in neat columns (hence the name), not indenting – they have been re-purposed/abused for this task. You can end up with all sorts of trouble if you mix tabs and spaces so I agree with not using tabs for anything. I’ve always thought though that 4 spaces is rather excessive for an indent – you just end up scrolling horizontally after a while as your code soon disappears off the right edge of the screen. I use 2 spaces and it’s not exactly difficult to see what lines up with what when using that. Most modern editors will highlight matched brackets and the like anyway.

      • Oddball

        Why 4 or 2 spaces and not 3? In the “The Elements of C Programmng Style” it says that research proved that 3 is the optimal number.

  • FYI : There is an interesting podast “FIG, FUD & FOMO”
    discussion between Matthew Weier O’Phinney’s , Jeremy Lindblom , Paul M. Jones and Cal Evans
    to know more about the group. Enjoy :-)

  • Thanks for the blog post Hari, I’m glad we managed to reach consensus in the end.

  • Tomas

    PSR-0 and PSR-1 are great, but PSR-2 is another reason to move away from PHP and go to .NET, Java/Scala, etc.

  • “All PHP files MUST use the Unix LF (linefeed) line ending.” Good luck with that, Windows with be the single downfall of this requirement.

    • Tomas

      most good IDEs (eclipse, netbeans, etc.) support this so I don’t see a problem with this requirement

  • mario

    Wow. That derailed quickly into proclaiming personal coding preferences into “standards”. Also that would be very bemusing if large parts of the PHP community weren’t so eager about fads.

  • I think it’s very unfortunate that certain people decided to take what started as a great effort towards *substantive* interoperability, and co-opt it to push an agenda tabs-vs-spaces holy wars.

    If not for this coding standards mess, we could have had something genuinely useful and meaningful, like a common package format.

  • Lc

    I’m glad 22 people decided they would comply to some coding standards.

    I’m glad I’m not one of them so I can pick only what I want from that.

  • Where can I find CodeSniffer rules for this coding style?

  • I have been fighting years to apply code standart, i love it, you have my vote, i love all your suggestings, good luck.

  • I’m not opposed to following somebody elses coding standards, as long as they are paying me by the hour. If I am not getting paid by the hour, I’m going to code the way that suits me best.

  • John May

    Standards are awesome, especially when it comes to coding.
    Working in the JavaEE industry for more than 15years (OMG I am getting old) now, I came to the conclusion that once your own project team outgrows ~25 Dev’s, you should develop YOUR OWN coding standard. To speed things up take an existing standard and “adjust” it to your team/company/group needs.
    If you dont like to put “{” on a new line… don’t do it.
    If you dont like to use 4 spaces instead of 1 tab for indention… don’t do it.
    In the end, all that really count’s is that you already have a fully automated software product production cycle going (the whole shaboogle about continous build & deployment). Cause somewhere in there you will have YOUR RULES defined to check on YOUR CODE to foster YOUR PRODUCTIVITY. Then check your results: the code violations against your own rules.
    That way, discussions in the team about the “code style” are way more productive cause this way you can’t blame it on “the worldwide standard” beeing wrong. If your team finds good reasons not to follow PSR-0,1,2,3,4,5 then go for it, and screw standards! ;-)

  • Gintro

    I’m sorry but this is simply ridiculous,
    i’m all for standards but if you just say things like you MUST put a space after function, for, while etc.
    then you clearly are not a programmer but rather an annoying manager!
    And what happened to PHP is better than java because…(all the nonsense statements),
    seems to me PHP is trying to be like java now!
    And speaking of standards, a as namespace separator is not exactly what i call standard!
    and then we have functions like strtr, strlen, str_repeat,….
    PHP is full of ridiculous things like that!
    So why don’t they just focus on that first!!

    • jupaju

      While I agree with your agony about the very colorful function naming conventions inside PHP core, you are really mistaken. The coding conventions that are discussed here are made by the _users_ of PHP, not the _developers_ of PHP itself.

      As a consultant I embrace widely used coding conventions because it makes much easier to focus to the code itself instead of first learning what modifications to which convention the existing team has done and then making proper changes to my IDE to reflect them.

    • Ninj

      You are just absolutely _right_ about that part:
      “i’m all for standards but if you just say things like you MUST put a space after function, for, while etc.
      then you clearly are not a programmer but rather an annoying manager!”

      Standards are meant to get a community go the same way, but they think standard are aimed at turning people into syntax robots! Who cares if i put spaces before a brace in function name? Come on. Naming needs conventions, ok, as well as file organization, tab/space, and other things which can make a file look too different from one programer to another. But stop telling me “to get involved in this project let a space before every equal sign but not after a parenthesis”. It make me just not want to participate…

      • Hey Ninj,
        I have worked with code base written by different people. Some people keep braces below, some on same line some write all in a line etc. I felt annoying to look into the dirty code.
        When you see the code base follows the same coding standard then you feel like home. ie it.
        No one restricts, but for a good programmer he always try to follow the same rules.

        • Ninj

          Hi Hari,

          I think that we are telling more or less the same thing, at slightly different levels: a messy code is unreadable, i agree. When you know the standards used, you feel at home, i agree again.

          I was only noting that “exactly one space before a curly brace” does not differ enough from “no space before a curly brace” to call the resulting code a mess. Your example neither convinces me: i had never have any problem reading a code mixing braces below and braces inline. Honestly, if that annoys you, so you must be extremely sensitive to every tiny details in everything you read daily (like inter-charcater space in newspaper) and that alone makes life difficult.

          Again: “CamelCase for functions” is a good type of rule, while “one space before equal sign but none before semi-colon” seems like a nerds attempt to standardize evertyhing. What’s next? Function names must be between 8 and 12 chars?

    • If you are working on enterprise software, on a large team, well defined coding standards are essential. Think about 10 developers using a different format, checking in and checking out work from a version control system, and having their IDE update the DOC with their custom format every time. Then the formatting changes are stuck in the VCS history forever, it makes the changes very difficult to view, more difficult to maintain.

  • Roberts

    Not to be confused – article title and contents might seem misleading for some audiences (authors incompetence or intention). PHP-FIG is not and official PHP standards body. It has NOTHING to do with PHP core development, it is what it is – framework interoperability group. If You are PHP developer – You are in no way forced to implement, use, or worry about those standards, nor do You need to adapt them in Your existing or upcoming projects if You do not wish to do so. Those standards will
    a: 99% chance never implemented by PHP core
    b: be enforced to anyone outside framework communities of topic, and even inside them
    c: will not achieve anything else than a noise.

    PHP-FIG is a private, self-proclaimed body, as W3Schools is to W3C.

  • Mike

    My pet hate is people who put the opening brace on the end of a line instead of the start of a new line. When both start and end braces start on a newline the code is far more readable.
    , and it looks tidier. At least to me. Indeed in a book called ‘Code Complete’ it advises to do this, this book is all about good coding practise. It’s a shame most people didn’t read it!

    Just my opinion of course… and that of the author of that book.

  • Frank

    This thread is pretty hilarious. Clearly some of you are junior to mid-level developers or have never written software on a team. Standards are absolutely necessary (one day you will agree with me — once you’re out of diapers). If you don’t like PSR, don’t use it. However, your team absolutely should use *some* kind of coding standard/guideline — or your code base is going to become unmanageable.

    I personally think what the PSR team has come up with is great. I didn’t even know this standard existed until a month ago. I just used guidelines that are very similar to Zend & PEAR (with additional vertical whitespace). All of the major players in the PHP industry use PSR-like standards. Autoloading is the main reason for file/directory naming conventions. That way you don’t have to manually include every PHP file that you want to use in your project. If you don’t use autoloading, you’re missing out (or are just naive).

    If you’re arguing about tabs vs. spaces, you clearly have no business discussing standards. Tabs should never be used (in PHP) because tab width varies from editor-to-editor (VI uses a tab width of 8 by default, for example). Unless you force your whole team to all use the same editor (which never happens), then use spaces — I prefer 3 spaces.

    In the end, standards are there to help programmers find where files are at, and to make it as easy as possible for the “next guy” to pick up the code and understand it. If you’re used to newline bracketing, and some hotshot on your team uses end-of-line bracketing (because he/she doesn’t “like” standards), then your entire team will immediately be less efficient when skimming through “hotshot’s” code. Said hotshot will (more than likely) not last long at that company.

    Another thing that is very important is to use nouns and/or descriptive names for your variables. your code should read like a sentence as much as possible. Declare variables, use whitespace, use lots of comments, and try to make your code flow. Don’t get creative… write your code so people can/will understand it. Creativity is for design/architecture, not logic.

    • I agree with Frank. Standards for coding for any team whose size can be expressed with a cardinal number are vital. (So are executable specs/tests, but I still read PHPers railing against those, too. I haven’t hired any such for a decade, though.)

      “Good” developers tend to informally evolve their own “standards” as a patchwork hodge-podge of manual, intermittent, scattershot practices that “seemed like a good idea at the time” and didn’t cause obvious breakage in subsequent projects. Great developers integrate them into their toolchain automation, starting from a known point and adapting when absolutely necessary. Google decision fatigue; by reducing the number of decisions you have to make about the mundane details of your code, you free yourself to make better decisions about the things that matter.

Get the latest in PHP, once a week, for free.