Comments on: PSR-1 and PSR-2 to be Approved as Standardshttp://www.sitepoint.com/psr-1-and-psr-2-to-be-approved-as-standards/
Learn CSS | HTML5 | JavaScript | Wordpress | Tutorials-Web Development | Reference | Books and MoreSat, 01 Aug 2015 20:53:00 +0000hourly1http://wordpress.org/?v=4.2.2By: Rickhttp://www.sitepoint.com/psr-1-and-psr-2-to-be-approved-as-standards/#comment-17669
Wed, 17 Apr 2013 21:25:25 +0000http://www.sitepoint.com/?p=2890#comment-17669If 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.
]]>By: Jeff Dickeyhttp://www.sitepoint.com/psr-1-and-psr-2-to-be-approved-as-standards/#comment-17668
Wed, 17 Apr 2013 15:37:38 +0000http://www.sitepoint.com/?p=2890#comment-17668I 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.

]]>By: Frankhttp://www.sitepoint.com/psr-1-and-psr-2-to-be-approved-as-standards/#comment-17667
Thu, 07 Mar 2013 01:34:29 +0000http://www.sitepoint.com/?p=2890#comment-17667This 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.

]]>By: Mikehttp://www.sitepoint.com/psr-1-and-psr-2-to-be-approved-as-standards/#comment-17666
Sun, 17 Feb 2013 02:03:45 +0000http://www.sitepoint.com/?p=2890#comment-17666My 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.

]]>By: Robertshttp://www.sitepoint.com/psr-1-and-psr-2-to-be-approved-as-standards/#comment-17665
Sun, 06 Jan 2013 22:44:06 +0000http://www.sitepoint.com/?p=2890#comment-17665Not 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.

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?

]]>By: Hari K Thttp://www.sitepoint.com/psr-1-and-psr-2-to-be-approved-as-standards/#comment-17663
Sat, 08 Dec 2012 01:02:09 +0000http://www.sitepoint.com/?p=2890#comment-17663Hey 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.
]]>By: Ninjhttp://www.sitepoint.com/psr-1-and-psr-2-to-be-approved-as-standards/#comment-17662
Fri, 07 Dec 2012 11:48:51 +0000http://www.sitepoint.com/?p=2890#comment-17662You 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…

]]>By: jupajuhttp://www.sitepoint.com/psr-1-and-psr-2-to-be-approved-as-standards/#comment-17661
Sun, 02 Sep 2012 14:35:55 +0000http://www.sitepoint.com/?p=2890#comment-17661While 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.