I am trying to convince the lead developer of an open-source project I'm contributing to, to conform to the PSR standards (PSR-2 in particular) created by the PHP Framework Interop Group.

He is willing to adopt PSR-0 and PSR-1, but he is opposed to PSR-2. His argument is that PSR-2 is too inconsistent: opening braces for classes and methods MUST go on the next line, but opening braces for control structures MUST go on the same line.

I believe that the difference between classes / methods at one side and control structures at the other is not an inconsistency, in fact they are different things. I also believe that consistency between different projects is far more important than treating classes / methods and control structures like they are the same, and that consistancy between projects should outweigh personal preferences... but I can't convince him.

Are there any more arguments I can use to try to convince him to use PSR-2, instead of a seperate, yet-another coding standard?

2 Answers 2


There is a difference between a standard existing and a standard being adopted.

Standards are adopted only when either or both of the following happen:

  1. The standard makes sense and provides more value to the project that the "costs" incurred by conforming to the standard. Note that costs can take a variety of forms, including time spent in conforming.

  2. There is a standards body with enough leverage that they can force others to conform to the standard in order to participate in the domain. Hardware specifications are good examples of this scenario.

Apparently, you have neither of those cases occurring with your project.

"Yet-another-standard" standards occur in situations exactly like this. If part, but not all, of a standard makes sense, then domain participants cherry pick the parts they like and then wrap whatever else around it to fill in the gaps. De facto standards are frequently created this way, and if you look at the evolution of the SQL standard you'll see numerous situations where domain participants pushed the evolution of the next standard based upon functionality they had already delivered.

Sounds like you've got an in-road with PSR-0 and PSR-1. Start with those.

Lobby the organization responsible for PSR-2 and let them know why your project isn't adopting it yet. (Good) Standards bodies don't exist in vacuums and appreciate feedback from the domain. Perhaps you'll be able to affect PSR-3 and make it a little bit more palatable for your team.


Really sorry, but I think you are probably on the loosing side on this one. Coding standards are great, but the only coding standard that is worth the disk space on the project server is the one that is actually enforced by the lead developer during code reviews.

What your lead developer is probably saying (but in different words) is that he doesn't want to be spending the time in code reviews saying that brace is in the wrong place, and then having to justify it when the other developers start grumbling about his pettiness.

  • Thanks for your answer. However, the question is not wether or not a coding standard will be adopted, because he is in favor of using a standard. The question is which standard will be adopted, because he doesn't agree with the different treatment for methods/classes and control structures.
    – Nic Wortel
    Commented Sep 23, 2013 at 13:17
  • I think you may have misunderstood my answer, I'm in favour of coding standards, but they also need to be enforced in code reviews. I just think that having different rules of curly braces is asking for trouble at the enforcement stage. Commented Sep 23, 2013 at 13:29
  • I am not trying to convince him to use multiple standards, I am trying to convince him to adopt PSR-2 as the one and only standard. Without deviating from the standard by creating different rules for curly braces.
    – Nic Wortel
    Commented Sep 23, 2013 at 13:32
  • Why do you need to enforce a coding standard in a review? Tools exist for automatic code formatting, even some that integrate into version control or automated build systems. Code reviews should focus on things that can't be detected automatically.
    – Thomas Owens
    Commented Sep 23, 2013 at 13:48
  • okay, never worked on a project that enforced code standards by rejecting checkouts or failing builds. Even still, having inconsistent curly braces on an enforced standard would not be something I'd want to try to justify to developers pushing back against it. Commented Sep 23, 2013 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.