After reading some of the reactions from http://net.tutsplus.com/tutorials/php/psr-huh/ I’ve seen how much PHP needs standards.
Most of the hate, fortunately goes to the PSR-1 and PSR-2 which specify how the source code should be formatted. Since the nature of PHP is to be so open and non-restrictive, people are used to adopt whatever coding style fits them. I’m not saying other languages don’t have this ability but PHP just makes it more easy to do it.
Bbbut I love my tabs/2 spaces/8 spaces/whatnot indentation rules… And I love my own way of leaving a blank space then have the curly brace on the same row as the function definition.
Well, the great thing about PHP-FIG, and the thing that nobody gets it, is that they don’t force you to use any PSR in your code. Actually I don’t think anyone cares about how you code. So why should you care then?
For one, I’m sick of jumping from project to project or even from company to company and every time learn yet another way to format the source code/read it. Yes, IDEs and tools like PHP Coding Standards Fixer make it easy to format sources according to different standards but at the end of the day, wouldn’t it be more easy to just open a new project and see all the syntax that I know and I could use directly?
Even better, it would encourage contribution to the said project since people would know how to read the syntax already should you decide to go open source.
And I’m willing to bet that when you are using Zend Framework, Symfony, CakePHP, Drupal or any other project, you are adapting to the standards of that project. Granted, it’s not a big problem but you still need to do it. Not to mention if you are working in a company / open source project and others must work with your code.
Do you feel hindered in any way because of adopting this standard? Well no standard has its disadvantages but on the long run it would be such a great thing if people could stop arguing about how to format code and talk about how the code is written, how the code performs under heavy load, how the code allows new users to get the most out of it or how the code could be improved to allow more extensibility.
The point is that standards like this would allow you to focus on what matter the most and leave out the details. So why don’t you rethink your approach to them and see if you can become a better programmer by embracing change or help creating a better future for all of us?
What do you think?
PSR-1 and PSR-2 DO NOT SOLVE A PROBLEM… NO ONE HAS A PROBLEM WITH ADOPTING CODE STANDARDS WHEN THEY WANT TO CONTRIBUTE TO A LIBRARY OR WORK FOR A COMPANY…
Actually people have this problem, I have this problem, rarely but exists, luckily most of the open-source projects and applications I saw/work/read/write respected the FIG standards or ZEND’s, by accident or not (at least 90% of the rules).
PSR-2 can solve problems, only one simple example: new team or product with small differences in the coding style is looking for a coding standard, problem fixed : FIG did all the hard work and wrote a “Coding Style Guide”.
Why do we need them ? Because it makes our work easier, makes me happier, the coding is faster, applications better and overall a better world !
“Do you feel hindered in any way because of adopting this standard?”
No, because I’m adopting the standard specifically because I want to contribute to those code bases and/or work for that employer.
This is very different, however, from saying that I should necessarily adopt these standards in my own projects for something that has absolutely nothing to do with interoperability.
If I write a class or library with my own coding standard, and someone wants to contribute, they should feel comfortable enough to say, “I want to contribute to this, so I will adopt its standards for THIS piece of code.” I should equally feel comfortable rejecting their contribution or at the very least asking them to modify it to use the standards in place.
This is very different from saying, “I should write my code using this standard or else it will not be used” — or worse, implying that it cannot be used.
Ok, so you are not against standards, you are just against PHP-FIG standards.
You’d rather have 1000 different standards and variations rather that have only one because this way … what? I really don’t see it.
There’s a small issue here: you can’t have a standard if there’s a bunch of different conflicting options wanting to solve the same problem and there’s no conversion to a single one.
The hardest part of having a standard is to have people following it rather that get defined.
I do believe that at some point in the following years, 1-2, PSRs will be de facto standards and people will be argue about how they can be improved rather that the fact that they are here and they fill a long lasting need to have a common way of solving interoperability issues but they don’t want them.
And like FIG says: you are not forced to adopt any of their PSRs but do your really feel like re-inventing the wheel instead of improving it?
PSR-1 and PSR-2 DO NOT SOLVE A PROBLEM.
Namespaces didn’t even solve a problem. These problems rarely if ever existed. The point I was making, I thought, was pretty clear.
NO ONE HAS A PROBLEM WITH ADOPTING CODE STANDARDS WHEN THEY WANT TO CONTRIBUTE TO A LIBRARY OR WORK FOR A COMPANY.
If FIG simply said, “This only applies to code produced by FIG” we wouldn’t be having this discussion. PSR-1 opens immediately by claiming that it has something to do with technical interoperability. This is inaccurate for MOST of its rules.
If I ever write an interface and propose it to FIG I will use their standard to do so. But someone should not feel disuaded from contributing to my library or code because it doesn’t follow the same formatting code as some group has defined. Nor should anyone out there currently feel persuaded to “get on it” when it comes to converting their existing code.
How you do not see this as more divisive than unifying is beyond me.
I’ll try this again.
PHP-FIG doesn’t impose anyone anything.
If you don’t like them ok, use something else and bring solid arguments to the table when you argue against the proposals.
For some people PSR-1 and PSR-2 do solve a problem.
I, for example, am sick of jumping from one indentation to another, from one place to use the curly braces to another and so on. I just find it annoying to adapt every time I want to contribute to a project or, even worst, start working in a company. Sometimes without properly configuring my IDE I just can’t adapt to the new style.
PSR-1 and PSR-2 are out there just like Zend Framework Coding Style is or like Symfony Coding Style or any other numbers of various coding styles out there.
It just so happens that PHP-FIG needed one as well and published as it as set of two PSRs.
This also helps people to refer to them when picking a new project from scratch. If they were just a set of bylaws then they wouldn’t have created so much fuss about it. Nor could someone like me could point out to their employer and say: ok, instead of creating our own coding style, lets see the existing ones and pick one that the most of us like and lets include PHP-FIG one as well as they are a group who tries to unify interfaces used by frameworks in PHP and they are part of their PSRs (rather that bylaws).
If you feel that moving them to bylaws would end up the discussion on spaces vs tabs and focus folks on interfaces then go on the mailing list and tell them that.
The most solid argument you’re going to get. If you *still* don’t agree when you’re done actually reading and processing that this time, then I don’t care whatever be your response.
http://scriptogr.am/mattsah/post/a-useful-critique-of-psr-x
Yes, I actually just said agree with me or STFU
It seems like you have completely missed the point.
Namespaces DID solve a problem, PSR-0 helped us to autoload classes based on vendor and package names, to avoid conflicts. between code packages.
Before That_Ever_Class_Was_An_Underscore and that was just pathetic, now its using a much more consistent namespace setup.
Quite right. Whatever your boss says goes, so if they have a style guide you use that. Whatever the original author says also goes, you should stick to his style guide.
PSR-1 and PSR-2 help in a two-fold approach to this.
1.) When a developer (or company) is looking for a style guide to adopt for a new project then instead of trying to work out if they should use the PEAR guide, or Zend’s style guide (which is of course moving to PSR-2 anyway) they have PSR-2 to aim for. This means overtime styles will become more consistent – but doesn’t mean existing projects have to change for the sake of it.
2.) By forcing camelCase for methods and a consistent naming pattern the interoperability factor is greatly increased, as projects using multiple components from different sources have a consistent style guide across then. PyroCMS is switching to use PSR-2, but if it didn’t exist then every package would be a mixture of whatever the hell a developer decided to do. PSR-1 means that form the outside looking in they all look consistent, which is important for any application that cares about quality code as you’ve already pointed out.
Have you ever even looked at the PHP-FIG website?
It says that right at the top of the page, its the first block of text on there with a link to the FAQ so you can read more.
Phil, with all due respect it seems you are the one missing the point.
I’ve addressed the “problems” PHP solved with namespacing in other areas, so I won’t re-iterate that here other than to say there is a very big difference between hypothetical problems and pragmatic problems.
With regards to your second point, on PSR-2 (which is clearly working out so well for FIG these days), the points I made in the article seem almost prophetic. You believe these things to be good for the community and beneficial to how we work together… I get that, I made similar assumptions about various proposals early on when I was much more active in community organizing (physical real world communities, not online). The problem which you, and no one else in FIG for that matter seems to understand is simply that, you’re wrong.
Now seems like a fairly opportune time to make this point, as if I’m not mistaken the guy who founded this whole thing just resigned over the obvious polarization which PSR-2 has brought to the table.
I know you and a large majority of other people think I just bring up these things to be contrarian and spout BS, but honestly, I hope that people in the community (including FIG itself) could learn a thing or two from said criticisms. It’s probably too late now… the mailing list reads more like a soap opera these days, and at least in my experience with non-internet community organizing, the minute it starts sounding like that, it generally ends similarly: a bunch of people die and nothing really ever gets figured out.
This brings me to my last point, which I thought, if not here then at least in my full article on this issue, was made clearly and strictly in the context of PSR-2. Yes, I have read FIG’s website. The point that I am making is not about some general mission statement. The point I am making is in the context of Florin’s point which was that the PSR-2 was designed to apply, for example, to something like PSR-3 which was actual code that came out of FIG. I’m (we’re?) not even talking about the frameworks who are voting members — this is strictly as it relates to PSRs which contain code.
It is clear from PSR-2 and the general mission statement, however, that such was not their intention, and as such, the point that I made about PSR-0 in my longer article applies also to PSR-2: