Skip to content

Use tabs, not spaces #35

wants to merge 1 commit into from

How did this even happen? You guys really think you represent the majority of the internet?

foglcz commented Jun 16, 2012


The only (really) devs I have seen use tabs are those who work on nette framework (which is awesome.) That is not majority of the internet.

FYI - not all people working with nette are using tabs, I have also seen a lot of people who are using nette + spaces.
Generally, prevailing ammount of projects I have seen in my life has been using 4 spaces as indent.

edit: I would rather see the whole section on indenting to disappear, instead of beign replaced by tabs.


I'm not saying we are. I'm saying using spaces is stupid and mainly selfish.

I agree that removing the section will be fine.


I totally agree with using tabs, not spaces. We have two perfectly supported ways of indentation:

  1. using spaces (everyone has to subdue to viewing them the same way)
  2. using tabs (everyone can view them in his own way)

Why on Earth would anyone prefer the first option except unability to properly setup his own IDE/editor?

But anyway: removing section will be fine :), yeah. No one should be forced to using tabs either.


Spaces are better because the code looks the same for everyone. It looks the same in IDE, same using cat, vim, diff, etc. The coding standards are mostly about the code looking alike even when it come from different developers. Last but not least using spaces you can fine-tune the indentation like:

$sql = $db->select()

AFAIK there are just a few projects using tabs - nette and wordpress being the most high-profile I know.


I don't care, if the code looks same for everyone, I wanna be able to setup the indentation how I like it. And that's possible only with tabs.

And using specific project doesn't prevent me from doing it my way. So the fact, that few popular tools use spaces doesn't mean everyone using them uses them too.


And with tabs code still can look the same for everyone :) - team members just have to settle on same tab-width.

pmjones commented Jun 16, 2012

A super-majority of surveyed member projects use spaces, so that's the origin of the rule. If the majority had used tabs, it would be tabs. See also here:

@pmjones pmjones closed this Jun 16, 2012

I have always believed that programmers are bunch of exactly-thinking people. What does the majority/non-majority has to do with opened issue? After reading your blog posts ( and, I still haven't found (and you admit it too!) any decisive argument, why spaces should be recommended. Wouldn't be better to leave this section at all?


Good thing you gods don't have a right to create laws.


@pmjones: „A super-majority of surveyed member projects use spaces, so that's the origin of the rule.“
So you, only 23 people, are trying to make rules for milions of developers. Interesting, don't you feel like dictators? I'm really missing some deeper investigation of the problem before making these decisions/assumptions, for example analysing the preferences of few thousands PHP projects (not only big ones and/or messy PHPBB or Wordpress).


I think that the indentation should not be part of any PSR-x standard.

pmjones commented Jun 16, 2012

A majority of the voting members disagreed with that position.

milesj commented Jun 17, 2012

Tabs vs spaces should be decided by the project or employer and not defined in a standard.

Also, I use tabs. It's just easier and faster to work with than spaces.

dg commented Jun 17, 2012

indentation should not be part of standard


Should be PSR standard for 20 big projects or for majority?


Yeah, I see the commits – 1000 files changed and in each of them 100 lines deleted, 100 lines added. No indentation rules in the standard, please.

Werkov commented Jun 17, 2012

HosipLan: I'm saying using spaces is stupid and mainly selfish.
HosipLan (an hour later): I don't care, if the code looks same for everyone, I wanna be able to setup the indentation how I like it.

Personally, I prefer spaces to tabs (better "portability"). And I agree indentation should be project/company specific.


dg: PSR is for majority. It's made by people working together - the FIG. People that have enough power to make it work. It's not like the "bad elitist zend framework created a standard for themselves and misused the 'php company' power to force everyone to use it". It a broad consensus of many different frameworks, that's based on discussion. You've chosen tabs as your own prefference based on your personal oppinion - ignoring Symfony, Zend, Pear, etc. - maybe you like to keep braces on the same line with definition - also it's personal. But there is no reason why anything that is not same as your personal way of doing thing should not be in the standard. You have two options:

  1. became voting member of the FIG and try to change it "from the inside"
  2. create your own "better" PSR, if you can find more people to agree on it than FIG did

You know, democracy is a bad thing, but it is the best we have so far! (i guess it was Churchill who said that)

JanVoracek: That's what git filter-branch is for :)

dg commented Jun 17, 2012

You know, democracy is a bad thing, but it is the best we have so far!


Elijen commented Jun 17, 2012

Because the majority uses it, we make it standard. Oh boy!

pmjones commented Jun 17, 2012

@tomasfejfar I'm glad to see that at least one person on this thread understands the nature and purpose of the PSRs. :-)

dg commented Jun 17, 2012

@tomasfejfar, @pmjones: This is absolutely not about promoting my personal preferences, my code is not PSR compatible and I don't care.

I understand PSR-2 as a set of guidelines for code formatting, rules that are so generic that should be considered a standard. And now there is a discussion about rule "Code MUST use 4 spaces for indenting, not tabs", because it is not obvious for many people.

I do not know any programmer who presses four times spacebar to indent. Are you doing it? Or are you using tab?

Maybe I'm the only programmer in the world that uses a tab, and then I'm sorry that I have discussed the rule and I'll remember that the super-majority is unerring :-)

Or maybe you could change the rule to "Code MUST use 4 spaces XOR tabs for indenting" and standard will be widely adopted.

foglcz commented Jun 17, 2012

@dg the psr-2 standard is already adopted by more than half of the php-fig members. As you don't care that your code is not psr-compatible, I see no reason why you try to argue about the psr standard itself.

Totally agree with @tomasfejfar and @Elijen

edit: see, the point behind PHP-FIG is, that even when with the psr-2 standard 7 members have voted against using spaces, the whole member community of FIG will implement this particular standard.
FIG is here so that when I try to make pull request to zend, I don't have to remember all particular nuances of zend framework coding style, file paths etc. When I try to fix something in, namely, nette, I do however need to find appropiate class via grep search.

As nette and/or dg is not member of FIG, I don't see the point behind trying to force into the FIG rules, which has not been approved by FIG. The FIG is here to make their lives easier, and because of the huge community behing member projects, to make innterop and collaboration easier.

redhead commented Jun 17, 2012

I don't know, but tabs have many benefits:

I don't have to press space 4 times to do indentation (oh, yes.. IDE!).
I don't have to press backspace 4 times to unindent - yes, some IDEs do that and no, I don't see it very useful at all, because I have never created a code that messes up indentation sizes.
I can set my own length of a tab. A friend of mine who had it set to length of about 8 spaces said he likes it that way because it's more distinguishable and more eye-candy for him. I don't object! I set it on 4 spaces because it's enough for me and my laptop screen isn't too wide.
Every space makes size of a file grow. With lot of lines of code and lot of files.. well, you can do your math and see what difference it makes.

When I think about it I don't see any single advantage of spaces over tabs, really.


+1 for this commit

How on earth could something as stupid as "use spaces" get into a project that calls itself a "standard"?

Tabs have many benefits (as already mentioned), spaces have almost none (as already mentioned) and tabs are made for indentation, putting there spaces instead is completely out of mind.

Your majority argument is more than funny. Coding styles must make sense and must be chosen for some practical and logical reason - not by following something that somewhere in your head is a "majority".

vrana commented Jun 17, 2012

I agree that tabs have some advantages over spaces and I also personally use them. Yet I understand that this rule have its place in the standard for these reasons:

  • There are references to soft limit on line length in the standard. What's the width of Tab? It's unclear.
  • I use a smart editor which detects if the file uses tabs or spaces (actually I implemented this feature). But not everybody is that lucky so I think that this rule shouldn't be removed from the standard or reduced to "Use 4 spaces xor tab". There must be some rule about this otherwise people will need to find out the project specific rule before contributing. This is one of the things that this standard tries to prevent.
Marax commented Jun 17, 2012

+1 @redhead for his arguments (BTW difference in size for symfony 2.0.15\Symfony\vendor\symfony\src folder is -0,4MB after refactoring with tabs)

@tomasfejfar fine-tune? I thought that you have to always use 4 spaces. Your code you use 4+4+2 spaces, what if you use IDE auto formating on this?

foglcz commented Jun 17, 2012

From my standpoint:

  • When using 4-spaces indent, I either don't have to press space four times. IDE does that for me with combination of tab or ctrl-tab for un-indentation. Most of the text editors I have came across do that in a same manner (pspad)
  • Personalization within the tab-length - when you have an IDE, that supports the variable tab-length feature, you also have IDE, which allows you to work the same way - just with spaces. The comfort is there, altough the "feeling from the code" is different.
  • As the "feeling of the code" is different, with TABS the line-length varies based on the IDE / editor. Hence, any limits on the line-lengths cannot be kept and it leads to the commit mess.
  • As per the filesize of symfony - 4 kilobytes is, well.. 4 kilobytes. (edit - my mistake, half-a-megabyte is kinda a lot, but still negligible compared to ammount of comments.) Try removing comments (as pmjones indicated in his article).
  • as pmjones wrote, the php parser itself thinks about whitespaces regardless whether it's one, two, four spaces or one tab. From the application execution standpoint, there is no difference in speed. (if so, I don't think it's more than negligible.) - update: as @dg noted, there is a difference. Didn't test it though, but I honestly think that after first compilation (running the already-compiled test) there will be exactly none.

So with spaces the only thing we are missing is this:
the code feel personalization

Therefore, we are avoiding commit mess because of different interpretations based on the variable tab-lengths.
Code standards by definition, are removing parts of the personalization - so that all code feels the same.

Apart from that, because most of the IDEs have tab-indent by 4-spaces by default, i advocate for the spaces. Therefore, most of the programmers these days are just used to this way of indent.

Pressing tab for indent !== having source code indented by tabs. At least in most of the IDEs these days.

dg commented Jun 17, 2012

(Just for correctness: there is a little difference in speed, 4 spaces was cca 8% slower in PHP 5.2 and cca 2,5% in PHP 5.3 than tabs in my simple testcase. But that's not an argument, just for correctness.)


I agree with @foglcz standard is already adopted and should not to interfere. I did notice that. My false. But I think absence of rules for indentation in this standard does not reach anyone.

@vrana also has partialy truth but I think that the indentation is not the slightest problem and should not be part of the language standard.

We have bigger "problems" with interface naming, use conditions, etc.

Just to clarify I do not want to argue whether spaces or tabs are better.

I just say use one of this variants in whole project.

evert commented Jun 19, 2012

Reading a bit into this discussion..

Both camps (tabs and spaces) are reiterating on a discussion that has been going on, and unresolved for years.
It's one of the most typical examples of a Holy War, and because of this you will not come to a conclusion that will be satisfactory for the other side. No matter how well your arguments are, and how correct you feel your standpoint is, if you think you can convince people to convert, you may be a bit disillusioned.

I think there's a better way to resolve this..

Both the tabs and the spaces camp shall pick a champion and fight to the death. The winning camp gets to set the standard, and the losing camp will have to bow down to the superiority of the winning indentation style.

Seriously.. the PSR has been defined, this ticket is closed and discussion should happen on the mailing list. But you will find little support if this argument does get brought up again; as it's entirely pointless..

For what it's worth.. I doubt that PSR-2 will get as much support from the wider community PSR-1 may get, as there's not really that much of an interoperability penalty if you don't. People have their own styles, and I doubt that a lot of people will actually be affected by this. PSR-2 got barely a majority, whereas PSR-1 was near unanimous.

But for the people that look for a simple foundation for their own coding style document, PSR-2 may be a good basis. Or not! Up to you! You could even say "We use PSR-2, except we use tabs for indentation". Nobody who will scold you for it, and it doesn't make you a bad citizen.

If you don't see the benefit of PSR-2, or heck.. standardizing on an indentation style, why is this worth arguing about?

For the tab people: find comfort in the fact that all the people who do use spaces will 10 years from now realize their grave mistake, and refer to this thread as the people who were right all along. You may even get an award for being the last men standing and defending the great glory of the tab.

milesj commented Jun 19, 2012

Or we just don't set the standard? Done.

It's not that hard guys. If you commit to another project that uses tabs, then you use tabs, if they use spaces, then you use spaces.

But for the most part, you work in whatever you feel like, and especially what your own projects or your employer want.

pmjones commented Jun 19, 2012

@milesj You said, "If you commit to another project that uses tabs, then you use tabs, if they use spaces, then you use spaces."

This misses the point of a shared guide. Quoting from ...

Q: Why can’t the rule be “use either tabs or spaces, as long as you’re consistent within a project?”

The focus of these recommendations is not “indivudal projects by themselves.” The focus is on “working with/on lots of different projects.” If one project wants to use tabs, cool; if another wants to use spaces, fine; but if you end up working on both, you want the rules to be the same for each one. Thus, we have to pick something to apply identically across lots of projects at the same time.

milesj commented Jun 19, 2012

But the point is still being missed. A good half of the people are going to completely ignore this rule.

pmjones commented Jun 19, 2012

I don't know if "half" is correct; I have not done a survey of all PHP developers in the world. Of the voting member projects, the number was about 1/3 using tabs. And if people want to ignore the rule, they are free to do so. They won't be PSR-2 adherent, but nothing says they have to be.


The problem is that these people are trying to set their own standards and apply them worldwide.
I do understand that these people are devs of the major projects, but I do not think a closed group of 23 people (+- 23 projects) is enough to be considered as a major part of the PHP community [1] (which is really large).
Since you are a closed group and you do not accept votes from the real community (e.g. open community voting), I think it's a bad idea to give you a subdomain on [2] as you requested. That would make your project appear as an official part of PHP itself, but it is not. :)


foglcz commented Jun 19, 2012

The problem is that these people are trying to set their own standards and apply them worldwide.

Nope. They set standards and apply them within member projects.
The decision about not giving subdomain is altough correct; php community is working on php - not on the frameworks.

breerly commented Jun 21, 2012

Awesome trolling :)

@stephpy stephpy commented on the diff Jun 21, 2012
@@ -722,9 +720,7 @@ A summary of what line the opening braces go on for classes, methods, and contro
### A.3. Survey Results
- tab: 7
- 2: 1
- 4: 14
+ tab: 999999999999999
stephpy added a note Jun 21, 2012


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
dzuelke commented Jun 22, 2012

Nope. They set standards and apply them within member projects.

Actually, that's not true either, @foglcz. My project proudly violates the PSR-2 nonsense :)


@dzuelke you rock! :)

breerly commented Jun 22, 2012

I think you guys are missing the point of what standards are supposed to do. You're getting lost in the details.


They set standards and apply them within member projects.

@foglcz: Nope, they set standards, applied them within member project AND requested making them global (by hosting it under

@breerly: I think you are missing the point. This is not a standard, this is just a convention of very few projects, made by 23 people (projects), not by the community.

breerly commented Jun 22, 2012

@Majkl578 - would you rather see a vote across the board? Might take awhile but would allow for more consensus. I personally dont care what the standard is, I think that's petty, I'm just happy to have a standard.

milesj commented Jun 22, 2012

If you want a language with tab/space requirements, go use Python or Ruby.

stephpy commented Jun 22, 2012

You can be disagree with theses "standards", i think it'll not make "undefined tab" notice when you'll use tabs ...

You're may be right, They are may be right, something which make everybody agreed is too hard ...

23 people (projects)

Why these 23 peoples would be dictator or not able to make these conventions and you are ?

I guess you are able to not follow these conventions, without saying you're wrong !

breerly commented Jun 22, 2012

@milesj its not a requirement, its a standard. I doubt PSR will ever be enforced at the language level.


Why we are discussing a standard if the people wants keep they own style of programming?

A standard is a definition of some rules that all people must follow if they want make source code following the standard, I don't like some things but I know that I don't make software only for my own.

A standard is not for do people happy. It's defined because is necessary.

You are not alone, you don't programming alone, don't be selfish.


@yriveiro that's the reason for this pull request in the first place, people who wants to keep they own style don't look for standards

everyone who's here reading and writing is ready to support a standard, but to be honest i still fail to see the point of using 4 spaces instead of a tab - i'm currently supporting the "remove it from standard" option.

from what i read, no one is denying that tabs have some advantages (pretty hard to deny):

  • they are faster
  • they take up less space on disk
  • they take less/equal number of keysrokes depending on your IDE
  • they don't require a configured IDE to be bearable
  • they just work better with many online tools which can often be shared / viewed by other people (see jsfiddle for example) where you can just copy / paste and have readable / manageable code: to me, if you are using 4 spaces for PHP, your IDE is probably using them for HTML / CSS / JavaScript too (and that's worse, unless you minify)

only 2 reasons i got from the whole reading are:

  • fine-tune
  • line length

now: i hope no-one of you meant something like "4+4+2 to make things line up" when he wrote fine-tune. because that is utterly against the very idea of defining a rule for indentation in this standard. i hope everyone just meant counting the characters and place them knowing exactly the space required... but still. you are going to do things like:

$sql = $db->select()

[which is actually 4+4+2 and it's at least anti-standard, i hope it's a mistake]
things like this are personal, not handled by the standard and should either be standardized or avoided anyway, IMO

if someone is using a 8-space tab indentation, it's his own problem. he's going to be more bothered by a 4-space indentation which is both against his personal taste AND his IDE configuration anyway to enjoy a "fine-tuned" call chain

and if someone is using a 8-space tab indentation, he's probably on a wide screen so he can afford some more line length.

and i don't think you can force anyone to view things the way you want. he decided to have tab size as 8 characters, he knew it's not standard, his choice / hurdle to handle. the data it's still the same for anyone and if he can / want handle it, no reason for not let him

my suggestion is

  • remove the section
  • change line-length to specify tabs MUST be considered as 4 spaces in the count
dzuelke commented Jun 25, 2012

Sorry @inalyricalcoma, but you're missing the whole point of tabs... you should only ever use them for indentation, never for alignment.

Example (both value lines indented with one tab; key lengths aligned with spaces):

$foo = array(
    "bar"  => "baz",
    "ohai" => "wat",

Similarly, in your example above, you would use exactly ten spaces in the second and third line to make sure that regardless of the number of tabs used to indent that portion of code, and regardless of the tab width the person looking at the code is using, things will line up.

And one argument pro tabs you missed is that some people have vision impairments or are dyslexic, and it helps them tremendously to have tabs set to eight or even 16 spaces width.

redhead commented Jun 25, 2012

@inalyricalcoma Nicely written post. +1 for the conlusion.


Ok, all argument are right, but we are doing a standard, not a guideline.

If we are not specified this kind of things, for homogenize and allow the interoperatibility between us, we will fail in our task, because everything will the same madness that now.

Tabs or spaces, but not "you can use that you most like".


@dzuelke thank you for your clarification - you are right on both points

i was actually quoting that as example of so-called "fine-tuning" but you are right about indentation / alignment matter, and that actually nullify the whole "fine-tune" point.

and talking about accessibility with tabs - which no one did yet - it's a good reason alone to use tabs for me

my vote goes to tabs, but apparently we are not voting, and it's pretty hard to reach a common ground - that's why i'd remove the section

dzuelke commented Jun 25, 2012

@yriveiro: coding style is completely irrelevant to interoperability. If someone can't understand my code just because I use a different indent character, or because my curly braces are on the same line and not the next, then maybe a different job might be a good idea for that person.

All other aspects are simply a matter of editors or other parts of our regular coding toolsets.

dzuelke commented Jun 25, 2012

@inalyricalcoma: one problem with tabs is that if you agree on a maximum line length, you can't really enforce it anymore because once again folks with four spaces per tab will complain about too long lines and the fellas with two spaces per tab will say "looks fine here".

Note the emphasis on "if". Why anyone would even define a max line length in a time where every editor out there has decent line wrapping capabilities is something I fail to understand.


"coding style is completely irrelevant to interoperability".

@dzuelke I'm sorry but I disagree. Coding style is the first step for make good code.

Legibility of the code is interoperability between us. If I can't read your code, I don't will use it. Therefore, the coding style issue is important for me.

I know that I'm being inflexible, but I repeat, this is a standard, not a guideline.

dzuelke commented Jun 25, 2012

You can't read my code because it uses tabs and not spaces? You can't read my code because I don't use a space after an opening brace? That sounds strange to me. I'm sure you can read such code just fine.

And anyway, at least I use an editor where I can configure, per project, whether the tab key generates tabs or spaces, so I don't see what the problem is.


@dzuelke i don't see that as a problem: i think we all agree that 4 spaces for indentation is a de-facto standard. plus, if you want to adhere with this standard you both know about it and you know your editor is showing things your way...

i admin it'll be hard to count the maximum line-length being variable, but it should not be too hard... you can do a lot of things to check your file once you finish your edit... and it'll only affect a few lines anyway.

finish your edit -> check the few long lines with 4 spaces/tab... it's either pretty basic math or a couple clicks to change your settings, check, and go back to normal... once each file/commit


anyway, i agree with dzuelke: given that code is overall tidy and indentation is right, tabs or spaces are not a deal, neither are spaces before / after brackets etc...

i find other things much more disturbing:

  • variables inside double-quoted strings, sometimes they are easy to spot, sometimes they are not. it's much more easier to see if they get concatenated
  • nested while / for / if without brackets
  • nesting control structures and sometimes skipping brackets
  • fragmented variables' declaration
  • long conditions and assignments inside control structures
  • overcomplex control structures
  • etc...

(just to list some which come to mind as examples)

i think some of these things can and should be standardized.
i really appreciate the intent of PSR-1 and i think that can be useful, but i feel like PSR-2 is looking in the wrong direction, just my opinion of course

edit: i know some of the things i listed can be helped / solved with a proper IDE, but i think you can't assume people will do their best to see things right, and then force them to 4 spaces because you want to be sure they'll see things your way


@inalyricalcoma: Nice summary of why tabs are better. I think it pretty clearly shows that tabs are better than spaces and why.

I still fail to understand why four spaces should be better than one tab of a defined/expected size of 4 spaces. They're optically just the same.

pmjones commented Jun 25, 2012

Neither tabs nor spaces are "better." Some disadvantages of tabs are listed here: As with all things, you get to pick your tradeoffs.

The primary benefit of picking one over the other is not any technical superiority. The primary benefit is standardizing on one or the other so that developers know what to expect when switching among differing codebases.


@Majkl578 if it's set the tab for uses 8 spaces characters it's not the same. 4 spaces always are 4 spaces, a tab can be what you want. The "fight" here if it's more "correct" use 4 fixed spaces or allow the programmer uses what he wants.

Either way the @inalyricalcoma's explanation cover 99% of question about tabs.

pmjones commented Jun 25, 2012

New commenters: please note this pull request is closed and will not be merged. Those who feel tabs are superior will be disappointed by this. If you wish, you may expend your energies here to soothe your sense of outrage, but it will be to no avail.

milesj commented Jun 25, 2012

@yriveiro Im not sure you understand the word interoperability.

Regardless, I stopped applying PSR after 0.


@milesj maybe I'm wrong but for me is "the ability to work together". Either way the pull request is closed and more discussion about this issue is a waste of effort.


I am also very disappointed that the single biggest mistake ever could find its way into the result of some so called experts on the matter. some day tabs will rule the world and you will look like fools. I stick to cake and other frameworks who know their programming (most of the time anyway^^).
at least you have been warned by quite enough people now (even more probably just shake their head in disbelief and stay quite and cry).


I have a great idea! Since this pull request is closed, maybe we could start arguing like 5 year olds over if FIG should adopt a comma-first or comma-last standard! Trolling FTW! \o/

breerly commented Sep 20, 2012

lulz at @dereuromark "some day tabs will rule the world and you will look like fools"


@tomasfejfar This standard will lead to an increase in RSI among PHP programmers. You may be able to create them using a single key, but in most editors won't help you while using the arrow keys to navigate. At least the Ruby community was wise enough to use only two spaces.

As for your example @dzuelke pointed out tabs should only be used for indentation (ie. when they are the first characters on a line). Personally when trying to do something like the example you gave I wouldn't even bother with spaces for alignment and instead just use tabs like this:

$sql = $db

Instead of spending so much time debating on what keyboard character to use for indentation could we focus our time converting our projects to be PSR complaint? There's sniffing tools like PHPCS and Fixers available to ease the update process. Pretty please!! :-)

We released the standard and closed this issue off months ago, it's about time we all started batting for the same team in the same direction. Go team go!


@dragoonis You just say that because you were on the "spaces" team. If you really understood why tabs are better, you would be fighting the good fight too.



@bobthecow actually dude, I was on the tabs team, the PPI project was fully tabs-based, however as the majority of projects used spaces then I was happy to go with the majority decision and convert to be PSR0,1 and 2 complaint ;-)


On, Dear GeekyGodInTheSky - please, please, please, do not even consider changing the tab -vs- spaces. That's the source of all long, ridiculous passionate forum battles. Families break up. Marriages end. If memory serves me right, we lost 4 PHP devs in NetTuts last time the argument broken. Broken glass everywhere. Had to close the place down for a week just to clean it up. Bury it. Then bury the shovel you buried it with.


@dragoonis: Don't be arrogant (or at least pretend not to be), thanks.

majority of projects used spaces

This is interesting. Did they (you?) check all the projects around, even those that are closed-source? I don't think so, so don't argue with something like that, because you are lying. Also, did you put a public poll somewhere (homepage of to let all devs around world to express their opinion? No, you did not, you just took some projects you found out there, made them "majority" (how funny) and said all the world uses spaces, lets make it a standard.

Finally, let me notify you, that PSR and FIG group itself are NOT approved by or part of PHP itself. PSRs are not even a part of language itself. You're just pretending to be a middle of universe.

milesj commented Feb 25, 2013

Before the PSR was approved, I remember looking at many projects and most of them used tabs. It was surprising and confusing why spaces won, or why either one of them was chosen.


@milesj - There was a survey of standards for the membership projects, the data was published. Probably easy to find with Google. If you look and can't find it, let me know and I'll dig around.


@Majkl578 - sorry, didn't mean to ignore you - just saw the last post. But, I think you are asking the same kind of thing. I am not a member, just observer, but they don't try to be the universe, just who they are - the membership. Projects can join, there is a process to do that. But, probably for the reasons you are saying - they are not the middle of the universe, etc., they don't pretend to be. That's why the survey is for membership. So, in a way, they are doing what you seem to be saying they should do. You guys agree. =)


You're just pretending to be a middle of universe.

Completely agree. Thanks god didn't give you subdomain ;)

Just use tabs finally, spaces are lame.


From the PHP-FIG website:

What is FIG?
The idea behind the group is for project representatives to talk about the commonalities between our projects and find ways we can work together. Our main audience is each other, but we’re very aware that the rest of the PHP community is watching. If other folks want to adopt what we’re doing they are welcome to do so, but that is not the aim.

The purpose of the group is to standardise things between the member projects. PHP-FIG does not claim to represent the PHP world in general, and the group does not force its standards on anyone - not even its own members. Don't like PSR-2? Don't use it.

The "majority of projects" mentioned here is referring to a majority of PHP-FIG member projects, not a majority of PHP projects in general.

In any case, the standard is written now, I can't imagine it being changed at this stage, and this issue has been closed for 8 months. I don't think the voting members are likely to be swayed to reverse this decision, and especially not by arguments that completely miss the point of the group.

Can we all just agree to disagree and stop this (absurdly repetitive) conversation here?


I can't imagine it being changed at this stage

Really? Why? Well I can imagine it very easily, it is completely normal to admit a mistake and correct it. And this was a huge mistake. (And converting spaces to tabs can be done completely automatically.)

I don't think the voting members are likely to be swayed to reverse this decision

So why don't we ask all the members? Let just everybody read this discussion, put a poll for a wider public somewhere and ask the members. We'll see.

and especially not by arguments that completely miss the point of the group

So the point of the group is just to create a "standard" but not a good standard? Well, congratulations then, dictators.

rvbhute commented Feb 25, 2013

and especially not by arguments that completely miss the point of the group

So the point of the group is just to create a "standard" but not a good standard? Well, congratulations then, dictators.

The point of this group is to improve co-ordination between framework developers so that the frameworks become modularized and eventually allow end users to swap out components at their discretion. PSRs are a facilitating step in that direction and they are the core group's prerogative. If you are not developing a framework (as opposed to just using it in your project) that will co-exist with other FIG frameworks, feel free to ignore the PSRs.


gee people chill out. It seems that some people do not understand what "voluntary" and "cooperation between participating projects" mean. I'm not a fan of spaces it angers me that I have to walk 4 spaces rather than a tab (keyboard sucks and "home" button is too far) but
voluntary means you do NOT have to use it
and PARTICIPATING most likely does not mean YOUR.
So, being nice, here is my advise (take it or leave it)

switching to spaces is just as easy as switching to tabs - do it and cry your sorrows to the pillow

do not adopt Psr-2 and go on with your life - don't waste your time and most definitely don't waste our time

want a vote on changes and/or new VOLUNTARY standards? submit your project, but be prepared to get rejected if your user base is not big enough.

Take care.


/me thinks @gerrywastaken did this on purpose, who in their right mind would bring to life a five month old open internet "this is where the freaks live" discussion on tabs -vs- spaces, for crying out loud? switches to 'Ignore thread'


The question whether to use PSR or not is absolutely irrelevant. What this is about is trying to make PSR good and get corrected such mistakes as spaces for indentation. I also think there was a huge mistake in the decision process - your majority is just a bullshit. Just taking quickly some of the most important projects in PHP - and yes, all of the following use tabs:

  • WordPress
  • Joomla
  • CodeInteger
  • CakePHP
  • Yii
  • LessPHP
  • Fuel
  • Kohana
  • ApiGen
  • Nette Framework
  • Texy
  • Dibi
  • Lithium

And who uses spaces? Of course - Symfony, Doctrine and all the stuff around, all the bundles, Assetic, Twig, etc. First of all, thats just a very particular small group of people and second, many of them use tabs just to be PSR compilant. Haven't I mentioned enough arguments (and all the other people - see the huge discussion) to at least think and discuss about some revision on this topic?

And please, stop your stupid "if you don't want, don't use it", it's normal to discuss about things in the OpenSource world and it's normal to try to make things better. Btw. if you thing your dictatorship doesn't influence project that are not involved, you're mistaken. Your "PSR compilant" can damage other projects that are not PSR, because many people can believe "oh, they are keeping some universal standards, cool, they're better".

Finally, if you want to do such things as standards, you have to discuss with people and try to make it good. It seems to me that it has fallen into completely wrong hands.



Until you understand the purpose of PHP-FIG, you aren't going to understand why what you're saying is irrelevant. Please read the FAQ at


@JanJakes What you do not understand is that the projects you listed are not some projects, that were banned from FIG. These are just those that did not care enough to participate. If all of them would be part of FIG, than the vote may have been entirely different. But mostly they were not and are not. They can become voting members of FIG. They can shape the way the next PSRs will be created. But most of them don't want to.

I want to specifically note here, that some tab-using projects are part of FIG (Lithium, Joomla), but they were simply outvoted by the majority using spaces. Please note that majority means "majority of projects participating in FIG" not "majority of the intewebz" :)

TabFIG can be created as well as FIG was. And they can have their own TabPSR. No one will object. These standards are use-at-will.


@JanJakes Your use of bold is emphasizing something you did not intend.

This is how it works. It does not work any other way than this. Even if you don't it, it still works this:

This is the membership. IF your project is not on that list, you are not beholden to the dictatorship. You are free. Even those projects in this list, do not have to comply with the dictatorship. (Of course, they are the dictators since they vote on their rules).

The PSR are shared rules for these projects. You can use their rules if you want. But, that's only by choice. You don't get to change their rules simply because you want to use them. They have the right to set their own rules up. You do not have the right to tell them they have to change their rules for you. If you did have that right, you would be the dictator.

People in the membership vote.

People not in the membership do not vote.

If you want to be in the membership so that you can vote, click the link from @pdmulvey to learn how.

Nate Abele: Lithium

Nils Adermann: phpBB

Brett Bieber: PEAR, PEAR2

Guilherme Blanco: Doctrine, Doctrine2, et al.

Jordi Boggiano: Composer, Packagist

Karma Dordrak: Zikula

Paul Dragoonis: PPI, PPI2

William Durand: Propel, Propel 2

Andrew Eddie: Joomla

Cal Evans: the community at large

Larry Garfield: Drupal

Ivan Habunek: Apache log4php

Paul M. Jones: Solar Framework, Aura Project

Robert Lemke: TYPO3 Flow, TYPO3 Neos

Larry Masters: CakePHP, CakePHP 2

John Mertic: SugarCRM

Ryan Parman: Amazon Web Services SDK

Evert Pot: SabreDAV

Fabien Potencier: Symfony, Symfony2

Andre Romcke: eZ Publish

Paul Scott: Chisimba, C4

Phil Sturgeon: PyroCMS

Lukas Smith: Jackalope

Kris Wallsmith: Assetic, Buzz

Mike van Riel: phpDocumentor

Matthew Weier O'Phinney: Zend Framework, Zend Framework 2

David Zülke: Agavi
Elijen commented Feb 25, 2013

Thanks to @ashnazg I finally understand it.

The PSRs are not standards. They didn't make it for PHP community to help maintain open-source projects. PHP-FIG is just group of people who say: "We are doing it this way. Join if you like it. Fu*k off if you don't."

Now I understand, why many projects avoid PSR.



Only those who are in projects in this list, must comply with the dictatorship. (Of course, they are the dictators since they vote on their rules).

Actually, even this is incorrect. Voting members are not required to follow the PSRs either. Nobody is required to use any of these standards.

It's all right there in the FAQ.


I stand corrected @pdmulvey

Even those projects in this list, do not have to comply with the dictatorship.

Fixed, thank you sir.


@Elijen - So basically you are saying that these projects who have agreed to work together, are not free to do so, even though other projects could join in if they wanted, because _______________ (please explain why)

That's the part I don't get. Why aren't they free to collaborate on their own free will and allow others who wish to join to do so?

Seems like you are the dictator, taking their free choices from them. Maybe I am not understanding you? Could you explain the way you think it should be?

Elijen commented Feb 25, 2013

@AmyStephen Of coarse the projects are free to work together, have standars they discuss just with members and not to care what say "the rest of the world".

The problem is many people outside of the PHP-FIG understand PSR as The Standard and adopt it in their projects. They somehow depend on decisions made by PHP-FIG. I don't say it's dictatorship.

The analogy with amusement park mentioned by @ashnazg is wrong as there are too many people outside PHP-FIG affected by the decisions.


@tomasfejfar said:

These are just those that did not care enough to participate. If all of them would be part of FIG, than the vote may have been entirely different. But mostly they were not and are not.

Oh really? Did someone ask them before, officially? No, I don't think so. Some people didn't even know about PSR-1 being prepared before it was accepted. So this is not a valid argument, to me its seems to be something like chicken-and-egg problem (you want them to join, but you don't ask them).

@ashnazg said:

PSRs are not industry standards, language standards, global standards, government standards.

@AmyStephen said:

The PSR are shared rules for these projects.

You, guys, are really wrong. Looking at the arrogant behavior of @dragoonis, I must admit that FIG group lost any respect I had to it before (if any).
All of you are arguing that these rules are only standards for member projects. This is luckily true, but… You probably missed the links to php.webmaster I mentioned above. Let me re-post them: and These posts clearly show the intentions of FIG group (or at least of the arrogant @dragoonis): to be world-wide, dominant and to rule them all. This is just selfish and bulls*it.

milesj commented Feb 25, 2013

Spaces and tabs don't help interoperability, that's just how it is. PSR should not suggest either one, it should be up to the developers and their projects.

If you are committing code to another project, use whatever implementation they use. It's not hard.

ashnazg commented Feb 25, 2013

The implication that seems implicit here is that it almost seems as though FIG must become a closed group, no longer publishing anything outside its own membership, solely so that its work is not misinterpreted as edicts applied to the world at large. The counterargument I see the most here is exactly that, "FIG has published these things, so we outside of FIG feel compelled and constrained by them, and we don't like it", but rather than let it go with "we agree to disagree", ...

Mostly, though, I'm saddened to see how personally people will take things during what really is a technical discussion... bikeshedding meets torches-and-pitchforks.


Tabs or spaces I do not care. It should be defined by the framework. The only thing I do care is that it remains consistent within the project. Nothing drives me more insane than opening a file and seeing it a mess due to tabs and spaces being interchanged (or when one developer uses tabs with a length of 4 and the other uses 5).

With that said, the reason for putting the requirement for spaces into the PSR is to ensure that this will not happen when a developer contributes to an interface. Since you cannot easily notice spaces and tabs when committing a change, having a rule about it makes merging in changes less error prone.

Using only spaces, and not mixing spaces with tabs, helps to avoid problems with diffs, patches, history, and annotations.

My Issue with this pull request is that the "author" just did a find replace of 'space' and made it 'tab' then stated that it was horribly wrong. The "author" also modified the vote section on the bottom to state that there where 999,999,999,999,999 votes for tabs (last I checked that is more the the population of the earth). I would have respected this "author" more if s/he worded the section as follows:

it is RECOMMENDED that code uses 4 spaces, tabs can be used but code MUST NOT use both

Adding a foot note stating that all accepted interfaces of PSR will be hosted here on Github with just 4 spaces as voted upon would have been fine with me.

This kind of bickering makes me worry about calling myself a developer. Any developer worth his/her merit knows that there is never one way to solve a problem or complete a task. I still to this day can't fathom why we can not just develop a little humility and accept that people are not going to agree with you or that you may be wrong about something.

Can we please put this issue to rest and focus trying to improve the PHP community?


This kind of bickering makes me worry about calling myself a developer. Any developer worth his/her merit knows that there is never one way to solve a problem or complete a task.

Well, this statement could also be extended to anything else, like putting opening curly parenthesis on new/same line.

Can we please put this issue to rest and focus trying to improve the PHP community?

I'd like to, but it seems there is no real response to the feedback (this PR), just nonsense arguments of the members. This is not improving of PHP community, this is improving of just few projects out there.

Sorry if you feel uncomfortable while discussing this, but there are no real benefits of spaces over tabs (instead, there are disadvantages) and accepting "spaces only" only because majority of projects use it just doesn't make much sense.


@Majkl578 how does your project code looks on github with it's 8-space tabs? :trollface:


The reason space vs tabs is a big argument all the time is it takes absolutely no skill, no talent, no effort, to pick and defend a side. You can play all day and never break a sweat. Congratulate yourself on your great points.

@Elijen - Much, much better, thank you. Take a couple of more short steps in that direction and ask yourself, who is responsible for someone's assumptions? Let it roll around - you'll get - you're pretty close.

@Majkl578 Did someone ask them before, officially? 

I don't know. Why should they? Is that just what you think should happen? Is it okay if others don't agree and choose to freely do what they think is best? Or, is it up to you?

@Majkl578 Looking at the arrogant behavior of @dragoonis, These posts clearly show the intentions of FIG group (or at least of the arrogant @dragoonis): to be world-wide, dominant and to rule them all. This is just selfish and bulls*it. 

When I look at Paul and watch him work, I see someone who cares, who knows if he wants to bring change, then he has to work for it. He is inclusive. He is available, responsible, considerate. He would never say the kinds of things that are being said to him. So, no, I disagree. I do not see selfish, I see giving. There is a good deal of bullshit in this thread but it's not coming from Paul.

 @Majkl578 I'd like to, but it seems there is no real response to the feedback (this PR), just nonsense arguments of the members. 

The issue is closed. What do you assume is going to happen? Is that a reasonable assumption for a closed issue?

I don't think people are uncomfortable - people just sick of others acting like they are entitled. Entitled to vote in a group they don't belong. Entitled to question what the membership decided for themselves. Entitled to call people who have worked to make this happen bad names. Entitled to expect an answer on a closed issue.

Gets annoying.

bzitzow commented Feb 26, 2013

It fascinates me that some in the PHP community are receiving the style guide as a personal attack / attempt to be controlled. No one has to adopt the standards. I'm grateful these people are organizing and creating the standards. With the code contributions from these projects, taking the initiative to standardize namespaces and auto-loading - they've given a lot of value to the PHP Community. There is no way standards could be created that pleased everyone. If you want to use tabs then use tabs. I can't help but be reminded of the words of Adam Sandler: WATER IS BETTER! :)


It fascinates me that some in the PHP community are receiving the style guide as a personal attack / attempt to be controlled. No one has to adopt the standards.


Here's an imaginary discussion from my head:

"Hey, friend. What coding standard does your project follow?"

"We follow the PEAR coding standard."

"Oh yeah? My project follows the PSR-2 coding standard."

"Cool, friend. Good thing we can each follow a standard we like!"

"Yeah! That is good."

Feel free to substitute Zend, Symfony2, li3, Drupal, Doctrine or PSR-1 — or really, any other standard — for the two mentioned above.

milesj commented Feb 26, 2013

And that's why I ignore a lot of the style guide rules.


So, I'm over the fact that PSR-2 chose space indenting even if I didn't vote for it (but am very thankful that the group did listen to early petitions and split the original PSR into two parts). However, does that mean PSR-2 should stay as it is forever? That's a good question.

While PSR-2 was born as a normalisation of the average, I think it can do better. I do agree that individual vendors should have some flexibility on some things - not too much, but some. So can PSR-2 be changed to accomodate this? I think it can be.

The standard could be changed to say that you MUST indent consistently with SPACES or TABS but not both (it's the mixing that's the problem). The standard could also recommend that sniffers MUST allow for individual vendors to configure which indent method they accept. We are in an age of automated tools that are highly configurable after all. This allows Vendor A and Vendor B to be PSR-2 compliant, but when contributing to Vendor A, they require spaces, and Vendor B requires tabs.

Default it to spaces if you want but, really, should interoperability hang on whether you use spaces or tabs? Probably not. It's a style decision so I think it's appropriate to put that in the vendor's hands.

I'm happy to sponsor such a change if people want that. If not, I have other things I can go on with ;)

Crell commented Feb 26, 2013

For the record, as the the FIG Drupal representative, I don't expect us to adopt PSR-2, ever. Doing so has no real value for us.

We have adopted PSR-0 for Drupal 8, and so far so good. We're also working at bringing in PSR-3 (the LoggerInterface), and I expect Drupal 8 to use that, too. Like any other project, we use what works for us and what we feel we'd benefit from and ignore the rest.

I encourage other projects (open source, not open source, FIG members, not FIG members) to do the same: Use the PSRs you would benefit from using, and ignore those that you wouldn't.

If you want more PSRs that your project would benefit from, put forward a proposal for us to discuss. :-) We have a couple we're working on now, on and off (caching, HTTP wrappers, etc.). Constructive feedback would be useful for all of them.

The solution to PSR-2 (which I also feel is something FIG should not have involved itself in) is to simply ignore it. It's a very effective strategy so far for Drupal. :-)

PSR's by definition cannot change once they've been issued, just like an IETF RFC never changes once it's been published. They may, however, be extended or supplanted by later PSRs, if appropriate. Lukas Smith (another FIG member) has said repeatedly that he'd be OK with "competing" coding standard PSRs. I'm not sure I agree, but conceptually there's no reason it can't be done. That wouldn't change PSR-2, though, so you can't "force" the PSR-2-using projects to switch to your preferred style. Sorry.


Wow, what's this whole discussion about? Just ignore PSR-2 and be happy about it. These are the rules for this game. If you want to play by your own rules, find someone to play with and have fun!


@demonkoryu Sure, and if there's 30+ of us we'll make it into a standard too... with blackjack and hookers :)


+1 @eddieajau I think that's wise.

you MUST indent consistently with SPACES or TABS but not both

Extended, supplanted, like @crell says, whatever word, doesn't matter, but take the argument out of something so insignificant is wise, IMO. Bigger fish to fry.

ldath commented Feb 26, 2013

+1 @manchuck
it is RECOMMENDED that code uses 4 spaces, tabs can be used but code MUST NOT use both


+1 for this.

As the readme states, you are "very aware that the rest of the PHP community is watching".
And as such many other frameworks or projects are taking a close look at what gets decided here.
I could not care less about what you guys are internally using. But you seem to develop a standard here that very much so affects other projects all over the PHP world (see the comments of others). Therefore you have to be very careful in what you state (if you do not have a disclaimer that clearly states that other projects should NOT adopt any of those standards and that you use faulty behavior for you very own reasons).
So as a result if you enforce spaces here, many that know that spaces are less suitable for indentation as spaces will see this a standard that teaches the wrong things. And as such this is not acceptable.

It is OK to use either tabs (which is the correct way of doing it) or spaces (there are reasons why projects need or want to stick to spaces) - and as such consistently throughout a project.
So just drop this line altogether (or adjust as noted above: `You MUST indent consistently with SPACES or TABS but not both) and nobody has to argue here about anything.

But many of us cannot leave this point standing without fighting for what is right - or against what clearly has gone way wrong here.
I don't like spaces being abused for indentation, but I accept it.
What I really cannot accept is that this is declared as good and healthy standard (and even worse tabs declared incorrect) and that others have to do the same thing to be on board of a standard that should actually bring frameworks and people together instead of segregating them.

ADmad commented Feb 26, 2013

I don't think these guys care about consistency either given the fact they chose to put the opening brace { on new line for classes and methods but on same line for control structures.


@dereuromark +1, The best comment so far. This is what it is all about.


many that know that spaces are less suitable for indentation as spaces will see this a standard that teaches the wrong things

This is when I decided to unwatch this thread.

Coding standards are not about wrong and right. Nobody, anywhere, will ever be pleased with all aspects of any coding standard. Full stop.

You choose as an individual, a project, or a community which standard you want to use, and then use it. The point is to use it, not to please everybody.

This standard largely is derived from Horde, then PEAR -- in other words, it goes back more than a decade, and has been used as the basis of CS for a ton of PHP projects, not just those represented in php-fig. Countless debates have occurred over it; this is just the latest incarnation.

Arguing on and on about a standard that's already been voted on and accepted and implemented by many is an exercise in hubris and futility. If you hate it, write and publicize your own standard.


+1 @weierophinney.

Now everyone, get back to actually writing code instead of worrying about whether or not you wrongly placed an open brace on a new line or what indentation method your project uses, which, by the way, should be tabs.

These standards were proposed for framework interoperability. If you are just writing code that goes in a composer package, feel free to ignore these. It's not like the php interpreter cares whether or not you use more than 120 characters on a line.


+1 for tabs. Spaces don't have any advantage (not even one) compared to tabs. You can configure tabs in IDE the way you like without modifiying the code; you can't do that using spaces (and this should be mentioned when using VCS).

milesj commented Feb 26, 2013

How about we use no indentation? That's the way of the future. Real men code vertically.


I still have yet to hear credible arguments regarding the use of spaces instead of tabs.

  • Tabs are tokens that are semantically identifiable ("\t" or "\x09")
  • Tabs allow individual developers to set indentation preference
  • Tabs help avoid incoherent spacing (3 or 5 spaces by mistake)
  • Tabs reduce an unnecessary file size overhead
  • Tabs were designed for text based table/column layouts using indentation and spacing

Can someone please just define a PSR-2.1, and we can all go back to work.


in other words, it goes back more than a decade

Are you serious? Do you even know what you are saying here? Is this standard here to preserve ancient history?
Or to do actual "good" in the PHP world? I thought the intention was to improve how "we can work together" in the present.

And are you still using PHP1/2? Or did you start using OOP, PHP5+ and all the other things the 21st century came up with? Will you ever be able to use PHP5+ if you don't even allow yourself to think about what is now at this very moment the right thing to do - and not what the case was back in those days the PEAR standard was established?
Be honest: Would you code today as you would have in 1999?

We are in 2013 - many decades after the computers have been invented. How we code has changed over time as well. We do not use stupid and lame text (or even less sophisticated and outdated) editors but IDEs (or at least notepad++).
So many times in history things changed. Why? Because that is just the natural thing. And at some point (many years back) it became clear that tabs should have been used here. This thread clearly states, that some of the most sophisticated programmers also came to the same conclusion. Even though I would like you to come to the same conclusion, I cannot force you to think this way.
And guess what: It does not matter if you just act now and modify that one line.

You might worship spaces. You might be too lazy or too long in the business to switch to tabs, or have 1000 other (some of them quite worthy!) reasons not to switch. That is ok. But you cannot make spaces superior to tabs here and proclaim this a PHP standard for frameworks in general. Then you need to call it "PHP standard for framework x, y, z"! You also slapped the other member frameworks right in the face which have already been using tabs for years (and justified as outlined by me and others).

Guys, it is not too late to realize that you made a mistake (it happens to all of us - all the time). That would be the honest and decent thing to do here. It is not too late to at least acknowledge tabs just as worthy as spaces here (I don't say you have to do any beyond that!). Put them on the same level and be done with it. This is how you preserve your face in the world outside of your scope. If you stick to what you decided without taking into consideration all the things that have been mentioned above, this standard is destined to fail - HARD.
Yes, some have been aware of the issue way after you decided on it. All the more my words should make you think twice and that you also consider the many voices which did not have the change to speak up earlier.

And yes, of course we could just produce a concurring PSR2A/PSR2tabs standard here. We would probably get quite a big user base in no time. What for? Nobody want's to compete with you. In the end we all want what's best for the PHP community in general.
If there is is one standard that is widely accepted (and there is still a chance for it), this will be way better than having tons of independent branches.

A standard evolves. This standard evolves (or should). The huge discussion here alone should be enough reason to justify at least some re-thinking if this standard has to evolve here (again).

So somebody please open a PR with the line change that equals both indentations and we can all stop fighting. This will be the wrong PR in this case anyway.

burzum commented Feb 26, 2013

:+1: for tabs

@jameswatts gave solid reasons for tabs and I don't see any arguments against what he said.

When I read that PSR is going to use spaces over tabs I was just like...


Must be a full moon bringing out all the jokers. So for those that actually want to engage in serious conversation, what then should we do? PSR-2 is set in stone never to change and the solution is just ignore it, or see if we can make some change and go the way of every editor that doesn't care what your opinion is and lets you choose?

burzum commented Feb 26, 2013

@eddieajau as I've said @jameswatts brought arguments to the discussion, others did not so far related to tabs vs spaces. I personally totally ignore the spaces part of PSR-2 so yes my solution is to ignore it.

So either create a PSR2.1 and allow BOTH or switch to tabs only. Tabs only would be the better solution because of the arguments jameswatts already mentioned.

pmjones commented Feb 26, 2013

Good news everyone! We have found an independent reviewer for PSR-1 and 2 and he agrees that they're all screwed up. Clearly the FIG was sorely mistaken on this issue. Here's the alternative our reviewer came up with; if you don't like PSR-1 and 2, use this standard instead:


@pmjones that's not being very constructive.

pmjones commented Feb 26, 2013

Pot, this is kettle: you're black!


So for those that actually want to engage in serious conversation

@eddieajau That's sort of the point: there is no serious conversation to be had here. If you're still trying to debate this, then by definition, you cannot be serious.

To be clear, this is coming from someone who thinks the standard is ugly. I had my day in court when it was debated and voted on, a majority of the others chose to go the other way, I choose not to use PSR-2. End of story.

Personally, I'm with everyone else who's hitting 'unsubscribe', but for the sake of everyone else's time, please let us never revisit this page, ever again.

@jameswatts If anyone around here has earned the right to a bit of snark, it's @pmjones.

pmjones commented Feb 26, 2013

/me bows to @nateabele


@pmjones :+1:

Again, everyone back to work, that includes the cakephp trolls.


Yep, back to work. Nothing will change. Move on.

dzuelke commented Feb 26, 2013

Some advice for those who get all worked up about this stuff here: all the nonsense is a lot more bearable if you simply choose to ignore it.

And that's coming from someone who's on the oh-so-important list of members and yet proudly not giving a boink about PSR-1 and PSR-2 (not only because tabs are clearly superior, but also because it adds no value to interop whatsoever).


@pmjones: If you don't have anything to say (which is sad since you are a member), please, be just quiet. Thanks.


How 'bout we look at the bright side: I love that the PHP community is finally organized enough to have a central place to rehash the same pointless argument that developers of other languages have been having as long as there have been programming languages.

Can we do the 1TBS argument next?

Elijen commented Feb 26, 2013

@eddieajau Why is the PSR-2 set to stone? Change from "you must use spaces" to "you can use either spaces or tabs not both" is obviously not a BC break. All PSR-2 compatible projects would stay PSR-2 compatible.

But this thread is no more about tabs vs spaces, anyway.

dzuelke commented Feb 26, 2013

Change from "you must use spaces" to "you can use either spaces or tabs not both" is obviously not a BC break. All PSR-2 compatible projects would stay PSR-2 compatible.

^ this. Please.

Seldaek commented Feb 26, 2013

@dzuelke IMO having two PSR numbers for tabs and spaces makes more sense, that way just looking at the PSR number you know, if we allow for either in one PSR, then it becomes PSR-2 with foo. That's a technicality though. The bottom line is, I don't see why anyone would be against that, so someone just runs with it and we can tune down the CS debates.


Even @pmjones must have seen that this thread is not anymore about spaces vs tabs.
So I really don't know how he could mock people who try to sincerely provide good arguments for a discussion here.
This only insults himself and the project he stands for as a member.

This thread - and most of its comments - is not a joke by itself (even after closing!). They are valid critism well layed out.
By not acknowledging this properly how could anyone ever take this whole project serious?

Again: The base question was wrong. I would even say: Invalid. You cannot ask the members to chose between "death or torture". You cannot make them chose between spaces and tabs and declare the other one invalid.
That was the source of all the trouble.

So the more valid question to vote on would have been:

  • tabs (which would be the ideal case, but the world never was ideal in the first place)
  • spaces
  • tabs or spaces are both valid (which all can agree on)
  • don't mention it at all (which should have happened)

Last two are equally "ok" here as it is the only common ground.
The rest would always discriminate some - which is obviously unnecessary.

By the way: For all that want to seriously discuss it further, lets move to the more appropriate PR that has been opened for exactly this: #91


PSR-2 is set in stone never to change

What? There's no plan on how to improve these standards? In 10 years there'll still be the same PSRs? Even if PHP makes some new syntax and constructions? Or how does it work? If there's no plan for PSR updates, than this whole project is completely ridiculous. And if there's a possibility to update PSRs (and it MUST be there), than where's the problem to seriously discuss tabs vs. spaces vs. using any of them again?

The fact that @pmjones doesn't want to discuss serious issues or maybe is not capable of doing that doesn't mean that it can't happen. With his last posts he has definitely won the title of the most arrogant and pointless comments of whole debate.

Btw. I definitely think defining some suggested coding standards in the PHP community is a great idea and I appreciate somebody is trying to do that. But it must be done the right way!


Btw. I thing defining some suggested coding standards in the PHP community is a great idea. But it must be done the right way!

There are tons of coding standards in PHP.

There have been coding standards in PHP for years. This is not a new thing.

Why can't people just pick the one they like and not try to force other people to comply with their own (completely subjective) opinions?

milesj commented Feb 26, 2013

The fact that tabs vs spaces exists, curlies on the next line for methods/classes but not for control structures exists, elseif vs else if, file ending with a blank line, file only in unix LF, and many other "style guide rules" even exist in some form, just show how ridiculously over-zealous PSR-2 really is. Now back to ignoring PSR-2 all together.


That's what I'm saying. PSR-2 is a style guide for PHP. Not the style guide. We're never going to be able to agree on just one, so why are people who don't like it incapable of letting those who do like it use it for themselves?


Just saying, I was using tabs myself, but implemented PSR-2 anyways, because ultimately, I care much more about consistency than about minuscule preferences.

See, the whole reason for a CS is that people don't have to mind such issues constantly while working with foreign code. And there's one whopping reason to use spaces in fact, and that's ASCII art that doesn't screw up when looking at it with different tab width.

I think there're different interpretations about what a CS is, why to use it, and how it comes into life. For me, a CS ensures that everyone is on the same boat coding style wise, and "same boat" means also "same intendation". Using a CS gives the benefit that people familiar with that particular CS will have an easy time reading and writing the code; in my book that's a good thing. And lastly, although everyone has different views, ultimately a decision needs to be made (in this case, by compromise and vote), because vaguaries serve no one; they are just unsettling and distracting.

TL;DR: Man up or leave it be.


@JanJakes I can understand your concern about PSRs not changing ever, but this issue has already been addressed (in this very thread) by Crell, the Drupal representative:

PSR's by definition cannot change once they've been issued, just like an IETF RFC never changes once it's been published. They may, however, be extended or supplanted by later PSRs, if appropriate.

So calling this project ridiculous may have been a bit hasty, no? ;-)

More on topic, I think the clearest course would be simply to ask the voting members if they see any merit in amending/superseding the offending PSR to the more neutral suggestion of using either tabs or spaces and not both. If the members pick this up, fine, otherwise (as has already been suggested many times) lets all just move on to bigger battles...

There is simply no merit in reviving a dead issue and the core of this discussion that does have merit really doesn't belong buried underneath a closed tabs-verus-spaces ticket.

At this point I am tempted to insert a cartoon for humorous effect but I'll constrain myself.


I think there are a few things not being taken into consideration here, that directly impact some developers because of this decision:

  • If I want to follow PSR-2 and use a code sniffer to check my code, but I want to use tabs, I'm forced to modify the code sniffer to avoid this rule (sometimes that isn't available for me to modify)
  • Unless I want to constantly tap the space bar 4 times I'm forced to use an editor or IDE which can interpret tabs as spaces (standards should never impose or introduce unnecessary requirements or barriers to entry for adoption)
  • It's been mentioned before that these standards only affect frameworks (which is an understatement in itself), however this also impacts people building on these code bases, such as plugin developers.

As already mentioned previously, amendments can be made to a specification once published, the version just needs to be enumerated correctly to convey it supersedes the previous proposal. A great example of this is the HTML 4.01 spec.

I think the gist of this discussion clarifies that introducing these rules as part of a standard was a big mistake. All I (and others in this thread) have suggested is that @pmjones, or the responsible committee, have the valor to admit to this, and, like the W3C, have a bit of sense and publish a rectified standard.

I think it's extremely important that the FIG take the community's distaste for this specific PSR seriously, as it has the capacity to undermine the credibility of the standards as a whole, which I personally think is very sad, as I feel the impact the FIG can have on the PHP community is for the greater good. But if you, @pmjones et al, intend on doing this to serve the best interests of the (framework) community, then it may well be a good idea to heed the criticism, and not resort to clever responses which just put in evidence your disinterest or disrespect for constructive arguments.

It's clear people are calling for a rectification to this standard. The least that could be done is to open it up for a vote, and let your proposal be put under a more open process of scrutiny. As out-lined by many already, a couple of the rules in PSR-2 have little or nothing to do with interoperability. I agree with not mixing spaces with tabs, but the "clarification" provided regarding spaces mentions the use of a "fine-grained sub-indentation for inter-line alignment". This is too ambiguous for a standard.

  • When should we use this?
  • Should an additional 4 spaces be used?
  • Or should we adjust in sums of 4 spaces to align with a section of the related code above?
  • What happens if this "fine-grained sub-indentation for inter-line alignment" exceeds the line length limit?
  • Should we continuously add "fine-grained sub-indentation for inter-line alignment"?

I'm well aware that standards are just a guide, but if you can't justify this with enough clarity it's obvious people aren't going to have an easy time accepting your reasoning. Hence, this thread.

I'd like to just clarify that I highly respect everything you (@pmjones) and the FIG are doing, and I commend your effort and resolve to make the PSR proposals a reality. But I feel, that in this particular case, there is certain intolerance happening with regard to the growing disagreement with PSR-2 specifically. Yes, we can ignore it, but wouldn't it be great if we didn't have to.

Here's to not opening another can of worms in the future.

burzum commented Feb 27, 2013

A lot comments later and we still have not a single, not even an invalid, technical argument for why spaces should be used over tabs and why they are better and what their huge advantages are while we've heard now enough technical reasons why tabs should be used. Is it that hard to find any real argument for spaces and to proof that this was not just a political decision or one of personal taste and preference?


For those interested in seriously debating the PSR-2 issue with the FIG there is a discussion on their Google group here:!topic/php-fig-cs/qVmUgK86YHs


@dereuromark "Is this standard here to preserve ancient history?"

No. The FIG (Framework Interoperability Group) Proposes a Standard Recommendation for it's members and published that standard. The standard was decided by majority vote. The goal of the standard was to help interoperability between the various frameworks that make up the group. It was a common ground.

"Or to do actual "good" in the PHP world?"

I'm sure using this as a basis for your own standard will make things much easier (and in effect do good). You can modify the standards to your needs, but keep what's already written for what you want to keep. It means much less work on your part having to define a standard.

"I thought the intention was to improve how "we can work together" in the present."

If by "we," you mean it's members, then sure. By extension, if you consider these Recommendations for your own projects, it will improve how you can work together with other people.

Tabs vs spaces does not change that.


Consider your own code, where you gleefully mix tabs and spaces for indentation purposes.

Simply put, you either use all tabs, or all spaces. The fact that the vast majority of people voting for tabs over spaces for indentation can't even follow their own rule (only use tabs, not spaces), it's best to use what the majority already use: spaces.


@jasonlotito your claim is false, there is only tab indentation in that file.

Please check your facts before you gleefully try to discredit others with false claims. Thanks.


@jameswatts I should have been clear. You use tab indentation in code, and then use spaces to indent comments, and then the DocComments.

Consider your use of


That's using a single space to indent the code.

Also, unless github is wrong, you are using spaces to indent your comments.

 * @copyright     Copyright 2012, James Watts (

So, unless github is changing your code, you are using both tabs and spaces to indent your code. You might disagree on the application, or even the meaning, but the reality is that you are using both tabs and spaces to indent your code.

dzuelke commented Feb 27, 2013

So, unless github is changing your code, you are using both tabs and spaces to indent your code. You might disagree on the application, or even the meaning, but the reality is that you are using both tabs and spaces to indent your code.

He is not. He is indenting with tabs and aligning with spaces. Which makes perfect sense because now, stuff in the code always lines up, no matter what tab size is set in an editor.

Not so hard to understand, or is it?

Seldaek commented Feb 27, 2013

This to me highlights the only valid reason to prefer spaces for indenting. Doing it right with tabs (+spaces for alignment) seems too complicated for everyone to do it, so I'd rather keep things simpler with only spaces, even if it means losing the flexibility of tabs. It's unfortunate, but not as much as having to look at broken indenting.


@dzuelke "He is indenting with tabs and aligning with spaces."

I understand this. The problem is when you have people who use tabs to help align, and ad a few extra spaces. Now, this might be wrong, but it also happens far more than you might think.

So, the question then becomes, do you use one, or both methods to format your code, and that's what we are really talking about? We can get into semantic arguments about indenting is what happens before your code and alignment happens after, but then the rules start to become more and more complex, and easier and easier to break.

Regardless, even still, this argument:

" stuff in the code always lines up, no matter what tab size is set in an editor."

Means that the biggest reason for having tabs, personal customization, is destroyed. I cannot customize james' code to my preferences.

You can't have it both ways.

Edit: I should point out that I find this entire line of questioning silly and pointless. PSR is not a standard that must be adhered to. Its' a Recommendation for a Standard for members of the FIG. Not even all the members follow it to the letter.

breerly commented Feb 27, 2013

I personally think there are far better places to spend our energy. Spaces are a largely accepted method of indentation across many popular languages. For little to no utility, having PHP be the only language that suggests tabs for spacing does not seem practical.

breerly commented Feb 27, 2013

I for one am completely pissed off about the namespace separator. Suggest another thread discussing \.

Is this even a real conversation?

ldath commented Feb 27, 2013

In Python I used spaces but for historical reasons in all PHP projects I used tabs. Converting my old projects to PSR without must have spaces was easy and something like { in other line is not a problem. But converting this projects to must have 4 spaces is like making diff with 100% code change. It's just to crazy. Starting new project with spaces and leave old project with tabs is problematic - change IDE settings every time I change project ?.

When I looked to this google group discussion I lost my respect for this FIG community.

Probably I faster fully migrate my project to Python then they start to listening others suggestions. This FIG standard in my opinion don't be really PHP standard of the future. I have hope in it but I lost it completely now.

I'm out of this discussion.

Sorry for my bad English.

milesj commented Feb 27, 2013

@breerly Don't even dare list those unofficial (most of them) style guides and use them as a basis for your argument.


@milesj They're about as official for their respective languages as a recommendation from the FIG is for PHP :)

ldath commented Feb 27, 2013

For Python PEP recommendations are official

Python - spaces -

It's strongly recommended to use 4 spaces only but using tabs is not banned

Never mix tabs and spaces.

The most popular way of indenting Python is with spaces only. The second-most popular way is with tabs only. Code indented with a mixture of tabs and spaces should be converted to using spaces exclusively. When invoking the Python command line interpreter with the -t option, it issues warnings about code that illegally mixes tabs and spaces. When using -tt these warnings become errors. These options are highly recommended!

For new projects, spaces-only are strongly recommended over tabs. Most editors have features that make this easy to do.

This is something I love in Python: use only tabs or only spaces or die ;)


@bobthecow I think he was referring to the github styleguides :P


I have been quietly following PHP-FIG since PSR-1 and this is my two cents: Everybody on that group has its own point. They suggest something, they discuss over the topic, some agree, some disagree, some propose changes. The chat starts over the new idea, they vote, and the most important part, they settle. Guys who voted against the proposal accept the fact and they all move on. The majority wins, because it is a democracy. They all speak their minds, discuss and vote. If you are majority, good, if you are not, deal with it. Democratically.
I understand you were not there. Your voice was not heard. Apparently because nobody invited you in.
But, wait... nobody invited none of them to join the group in the first place. Nobody invited me, but here I am.
What is the secret? Simple, I googled about it and voilà. See, I'm not a voting member. I rarely say anything at all on the list. The main reason I'm there is to understand why decision has been made this or that way.
When I first got there, voting members were no more than 8. Meanwhile, I saw a lot of new members getting in (and some out). Guess what, nobody invited them either, but they made their voice heard, democratically. No offenses whatsoever. No dictatorship, no name calling... believe it or not.
FIG members, I don't really think you should be so worried about this. I don't think Matthew should give "haters" that kind of power. We all know how these guys work. When the argument is weak they tend to shout it. Nevertheless, I understand his point and respect his decision.
So you don't agree with spaces or with the color of the bikeshed? Good, join the group, say what you think, listen carefully and gather people to vote like you. That is the process everyone takes. You could even replace the bad, bad PSR with a new, shiny one. In the worst case scenario, you will at least have real arguments to debate, because you too will know why decisions were made that way.
Sorry about my poor english.

ldath commented Feb 28, 2013

Really last comment - I was hoping that from this PSR in a feature will born a official PHP standard recommendation like PEP for Python. Like I said I migrate almost in 100% to PSR.

I see now that FIG don't wonted to go this way and I respect this answer. Than sorry for trying to convince you to be less aggressive with this tab politics.

Crell commented Mar 1, 2013

Historical point: When it was first created, the FIG group was called "PHP Standards", and did purport to be "THE Standards Committee" for PHP. The outcry was so loud (including from me) that the group was thrown off of and went dormant for nearly 2 years. So there's a very good reason a lot of people in FIG are loudly "these are for us, we don't care what you do, don't get on our case, we're not forcing anything on you!" Once bitten, twice as cautious. :-)

To those calling for FIG to "be more receptive to the community": The signal to noise ratio in this thread is too low for that to be possible. Really, when half the comments are variations on "you are a terrible human being for using spaces instead of tabs and you are actively trying to destroy PHP, you probably kill kittens for fun, too!", there is no discussion to be had. When someone comes on that hard, there is no opportunity to discuss anything. That's not "feedback from the community". That's "hey look, another internet troll who has nothing better to do than pick a fight from his mommy's basement."

Sure, that's not everyone in this thread. But it's enough of this thread that, frankly, this thread is now useless. The earth has been scorched, nothing more can grow here.

I'm openly hostile to PSR-2 as I think it was a mistake in the first place for the FIG to wade into this exact bikeshed bait. So I actively ignore it. But that doesn't mean going on a crusade to tear down it and everyone who supported it. The people on FIG are all rational, reasonable professionals. That they don't always agree with you, or each other, does not change that fact. No one responds well to a crusade. Those of you crusading to destroy Spaces Land are perhaps the chief reason why PSR-2 won't change. No one responds well to a bully.

If you want a rational, reasoned response from someone, it helps to start with a rational, reasoned proposal. If you start with vitriol, don't cry when you get met with flippancy.

ionas commented Oct 20, 2015

PSR2 is really broken for in practise recommending a software feature (2 or 4 spaces soft-tabs) over a standard ASCII character (tabs, which can be set to whatever) as well as its inconsistency in regards to parentheses.

Both should be fixed in a PSR-2 update (like PSR2-Revised).

@simensen simensen locked and limited conversation to collaborators Oct 20, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Something went wrong with that request. Please try again.