I have been following a group called The PHP Framework Interop Group, or just FIG for short, for some time now. Their main goal is to attempt to standardise the way PHP language is used in a form of A Standard or The Standard.

They have been making good progress and their coding guides can be useful for beginners. They set rules such as the way you should indent your code or how you should or should not put or leave out empty lines in certain parts of a file etc. Must of the “suggestions” (and I emphasise this word) were correct in my opinion.

However, as of recently, they have voted a number of articles into the standard with which I cannot fully agree and which I have absolutely no intention of adopting in my coding style when writing code in any of C-like (C-inspired) programming and scripting languages that I use.

One of the topics that does not sit well with me which were adopted by people proposing this standard is to put the braces which go after the class or method declaration on the new line after the declaration. I feel that writing code is like writing a book, or a story. When you write a story, it is important to spell correctly. However, handwriting is also a part of writing and this is something that teachers and parents and the general study environment can contribute to and influence, but cannot absolutely control and restrict alterations. Some would argue that the placement of the braces after class or method declaration is a matter of syntax and not a matter of “handwriting” or in this case “style”. With this I agree and I hope that those “other people” can agree that we disagree on this, because it is something that many programmers out there are going to resist because they feel the same way as I.

Therefore, regarding this part of the standard “proposed” by PHP FIG and their “Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body” and “Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body” statements I say that I will not adopt and follow. I do not want a nice holographic sticker on my code stating that it conforms to any one Standard.

Also, there is the issue of the “Code MUST use 4 spaces for indenting, not tabs” statement given by their standard. A crude calculation shows that about 5% of my PHP code files comprises of tab characters. Given that on the average, my PHP files are about 3 to 10 kilobytes, that means that tabs are up to about a half of a kilobyte. If I were to replace one of my preferred tab characters with 4 of their preferred space characters, I would be increasing the file size on average by about 10% to 15%. And why? Because some stuck up “standardizer” fella/gal is too lazy to set up his/her code editor preferences to “display” my tabs as 4 spaces. Well, too bad for him/her and his/her preferred editor’s default settings of 8 characters for one tab. This is another “suggestion” by the PHP FIG and their suggested standard that I will not accept.

I am aware that there have been many criticisms towards PHP FIG’s standard suggestions and most of the critics make a lot of noise, but give no suggestions. Unlike them, I have concrete suggestions. Do not try to make PHP rigid and conformed. The spirit of PHP is its flexibility and dynamics and freedom of choosing what works best for you. If you make PHP into a new BASIC or a new [place your favourite language that has fallen to chronic disuse here]. Leave some stuff to be as free as handwriting is. Whether or not I put by braces on the same line or on the next line is a matter of style, just like handwriting is. And whether I use one tab or four spaces shouldn’t matter to you. Your code editor is more than capable of “transforming” this to your preference. Don’t force others to conform to your needs. That way, you are smothering their creativity by enforcing too many restraints and limiting their flexibility.

For me personally, these newly adopted rules put an end to my supporting of your standardization efforts. It was a great run since the mid 2011 since I first stumbled upon your work. However, this was the last straw. There were many. Most of these issues that I have been talking about in this post have been around since 2013. Especially the braces issue. Until recently, it was uncertain whether or not it will pass the voting, but since it has and was included in the standard it marks my own personal schism with you.