Use tabs, not spaces #35

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
@fprochazka

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

@foglcz

This comment has been minimized.

Show comment
Hide comment
@foglcz

foglcz Jun 16, 2012

-1.

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.

foglcz commented Jun 16, 2012

-1.

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.

@fprochazka

This comment has been minimized.

Show comment
Hide comment
@fprochazka

fprochazka Jun 16, 2012

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'm not saying we are. I'm saying using spaces is stupid and mainly selfish.

I agree that removing the section will be fine.

@vojtech-dobes

This comment has been minimized.

Show comment
Hide comment
@vojtech-dobes

vojtech-dobes Jun 16, 2012

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.

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.

@tomasfejfar

This comment has been minimized.

Show comment
Hide comment
@tomasfejfar

tomasfejfar Jun 16, 2012

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()
          ->from()
          ->where();

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

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()
          ->from()
          ->where();

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

@fprochazka

This comment has been minimized.

Show comment
Hide comment
@fprochazka

fprochazka Jun 16, 2012

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.

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.

@vojtech-dobes

This comment has been minimized.

Show comment
Hide comment
@vojtech-dobes

vojtech-dobes Jun 16, 2012

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

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

@pmjones

This comment has been minimized.

Show comment
Hide comment
@pmjones

pmjones Jun 16, 2012

Contributor

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: http://paul-m-jones.com/archives/2312

Contributor

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: http://paul-m-jones.com/archives/2312

@pmjones pmjones closed this Jun 16, 2012

@vojtech-dobes

This comment has been minimized.

Show comment
Hide comment
@vojtech-dobes

vojtech-dobes 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 (http://paul-m-jones.com/archives/2312 and http://paul-m-jones.com/archives/276), 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?

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 (http://paul-m-jones.com/archives/2312 and http://paul-m-jones.com/archives/276), 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?

@fprochazka

This comment has been minimized.

Show comment
Hide comment
@fprochazka

fprochazka Jun 16, 2012

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

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

@Majkl578

This comment has been minimized.

Show comment
Hide comment
@Majkl578

Majkl578 Jun 16, 2012

@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).

@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).

@pmjones

This comment has been minimized.

Show comment
Hide comment
Contributor

pmjones commented Jun 16, 2012

@Vrtak-CZ

This comment has been minimized.

Show comment
Hide comment
@Vrtak-CZ

Vrtak-CZ Jun 16, 2012

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

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

@pmjones

This comment has been minimized.

Show comment
Hide comment
@pmjones

pmjones Jun 16, 2012

Contributor

A majority of the voting members disagreed with that position.

Contributor

pmjones commented Jun 16, 2012

A majority of the voting members disagreed with that position.

@milesj

This comment has been minimized.

Show comment
Hide comment
@milesj

milesj 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.

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

This comment has been minimized.

Show comment
Hide comment
@dg

dg Jun 17, 2012

indentation should not be part of standard

+1

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

dg commented Jun 17, 2012

indentation should not be part of standard

+1

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

@JanVoracek

This comment has been minimized.

Show comment
Hide comment
@JanVoracek

JanVoracek Jun 17, 2012

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.

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

This comment has been minimized.

Show comment
Hide comment
@Werkov

Werkov 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.

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.

@tomasfejfar

This comment has been minimized.

Show comment
Hide comment
@tomasfejfar

tomasfejfar Jun 17, 2012

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: 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

This comment has been minimized.

Show comment
Hide comment
@dg

dg Jun 17, 2012

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

Really? http://ancienthistory.about.com/cs/greekfeatures/a/democracyaristl.htm

dg commented Jun 17, 2012

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

Really? http://ancienthistory.about.com/cs/greekfeatures/a/democracyaristl.htm

@Elijen

This comment has been minimized.

Show comment
Hide comment
@Elijen

Elijen Jun 17, 2012

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

Elijen commented Jun 17, 2012

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

@pmjones

This comment has been minimized.

Show comment
Hide comment
@pmjones

pmjones Jun 17, 2012

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@dg

dg 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.

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

This comment has been minimized.

Show comment
Hide comment
@foglcz

foglcz 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.

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

This comment has been minimized.

Show comment
Hide comment
@redhead

redhead 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.

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.

@JanJakes

This comment has been minimized.

Show comment
Hide comment
@JanJakes

JanJakes Jun 17, 2012

+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".

+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

This comment has been minimized.

Show comment
Hide comment
@vrana

vrana 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.

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

This comment has been minimized.

Show comment
Hide comment
@Marax

Marax 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?

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

This comment has been minimized.

Show comment
Hide comment
@foglcz

foglcz 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.

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

This comment has been minimized.

Show comment
Hide comment
@dg

dg 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.)

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.)

@Vrtak-CZ

This comment has been minimized.

Show comment
Hide comment
@Vrtak-CZ

Vrtak-CZ Jun 18, 2012

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.

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

This comment has been minimized.

Show comment
Hide comment
@evert

evert Jun 19, 2012

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@milesj

milesj 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.

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

This comment has been minimized.

Show comment
Hide comment
@pmjones

pmjones Jun 19, 2012

Contributor

@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 http://paul-m-jones.com/archives/2420 ...

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.

Contributor

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 http://paul-m-jones.com/archives/2420 ...

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

This comment has been minimized.

Show comment
Hide comment
@milesj

milesj Jun 19, 2012

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

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

This comment has been minimized.

Show comment
Hide comment
@pmjones

pmjones Jun 19, 2012

Contributor

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.

Contributor

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.

@Majkl578

This comment has been minimized.

Show comment
Hide comment
@Majkl578

Majkl578 Jun 19, 2012

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 php.net [2] as you requested. That would make your project appear as an official part of PHP itself, but it is not. :)

[1] http://news.php.net/php.webmaster/13696
[2] http://news.php.net/php.webmaster/13687

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 php.net [2] as you requested. That would make your project appear as an official part of PHP itself, but it is not. :)

[1] http://news.php.net/php.webmaster/13696
[2] http://news.php.net/php.webmaster/13687

@foglcz

This comment has been minimized.

Show comment
Hide comment
@foglcz

foglcz 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.

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

This comment has been minimized.

Show comment
Hide comment
@breerly

breerly Jun 21, 2012

Awesome trolling :)

breerly commented Jun 21, 2012

Awesome trolling :)

@dzuelke

This comment has been minimized.

Show comment
Hide comment
@dzuelke

dzuelke 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).

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).

@Majkl578

This comment has been minimized.

Show comment
Hide comment
@Majkl578

Majkl578 Feb 26, 2013

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

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

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Feb 26, 2013

Contributor

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?

Contributor

bobthecow commented Feb 26, 2013

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?

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Feb 26, 2013

Contributor

Can the tab aficionados please check my reply on the list and share
their opinion there?

https://groups.google.com/d/msg/php-fig/-N56pNKtZHE/8OFuLX-Oi1UJ

Contributor

Seldaek commented Feb 26, 2013

Can the tab aficionados please check my reply on the list and share
their opinion there?

https://groups.google.com/d/msg/php-fig/-N56pNKtZHE/8OFuLX-Oi1UJ

@Elijen

This comment has been minimized.

Show comment
Hide comment
@Elijen

Elijen 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.

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

This comment has been minimized.

Show comment
Hide comment
@dzuelke

dzuelke 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.

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

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Feb 26, 2013

Contributor

@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.

Contributor

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.

@dragoonis

This comment has been minimized.

Show comment
Hide comment
@dragoonis

dragoonis Feb 26, 2013

Member

I'm just concerned about a whole new PSR just for an exception rule.

Can we maybe have dashes for sub-PSR's ?

PSR2-1 or PSR2-TAB or something. I think it's clear we're happy to setup a
new PSR document for tabs but a whole new PSR number seems a bit overkill.

On Tue, Feb 26, 2013 at 10:00 PM, Jordi Boggiano
notifications@github.comwrote:

@dzuelke https://github.com/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.


Reply to this email directly or view it on GitHubhttps://github.com/php-fig/fig-standards/pull/35#issuecomment-14142523
.

Member

dragoonis commented Feb 26, 2013

I'm just concerned about a whole new PSR just for an exception rule.

Can we maybe have dashes for sub-PSR's ?

PSR2-1 or PSR2-TAB or something. I think it's clear we're happy to setup a
new PSR document for tabs but a whole new PSR number seems a bit overkill.

On Tue, Feb 26, 2013 at 10:00 PM, Jordi Boggiano
notifications@github.comwrote:

@dzuelke https://github.com/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.


Reply to this email directly or view it on GitHubhttps://github.com/php-fig/fig-standards/pull/35#issuecomment-14142523
.

@dereuromark

This comment has been minimized.

Show comment
Hide comment
@dereuromark

dereuromark Feb 26, 2013

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

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

@JanJakes

This comment has been minimized.

Show comment
Hide comment
@JanJakes

JanJakes Feb 26, 2013

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!

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!

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Feb 26, 2013

Contributor

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?

Contributor

bobthecow commented Feb 26, 2013

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

This comment has been minimized.

Show comment
Hide comment
@milesj

milesj 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.

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.

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Feb 26, 2013

Contributor

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?

Contributor

bobthecow commented Feb 26, 2013

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?

@demonkoryu

This comment has been minimized.

Show comment
Hide comment
@demonkoryu

demonkoryu Feb 27, 2013

Contributor

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.

Contributor

demonkoryu commented Feb 27, 2013

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.

@Potherca

This comment has been minimized.

Show comment
Hide comment
@Potherca

Potherca Feb 27, 2013

@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.

@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.

@jameswatts

This comment has been minimized.

Show comment
Hide comment
@jameswatts

jameswatts Feb 27, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@burzum

burzum 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?

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?

@jameswatts

This comment has been minimized.

Show comment
Hide comment
@jameswatts

jameswatts Feb 27, 2013

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

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

@jasonlotito

This comment has been minimized.

Show comment
Hide comment
@jasonlotito

jasonlotito Feb 27, 2013

@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.

@jameswatts

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

https://github.com/jameswatts/cake-toolkit/blob/beta/Lib/CtkBindable.php

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.

@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.

@jameswatts

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

https://github.com/jameswatts/cake-toolkit/blob/beta/Lib/CtkBindable.php

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.

@jameswatts

This comment has been minimized.

Show comment
Hide comment
@jameswatts

jameswatts Feb 27, 2013

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

https://raw.github.com/jameswatts/cake-toolkit/beta/Lib/CtkBindable.php

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

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

https://raw.github.com/jameswatts/cake-toolkit/beta/Lib/CtkBindable.php

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

@jasonlotito

This comment has been minimized.

Show comment
Hide comment
@jasonlotito

jasonlotito Feb 27, 2013

@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 (http://github.com/jameswatts)

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.

@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 (http://github.com/jameswatts)

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

This comment has been minimized.

Show comment
Hide comment
@dzuelke

dzuelke 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?

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

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Feb 27, 2013

Contributor

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.

Contributor

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.

@jasonlotito

This comment has been minimized.

Show comment
Hide comment
@jasonlotito

jasonlotito Feb 27, 2013

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@breerly

breerly 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 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

This comment has been minimized.

Show comment
Hide comment
@breerly

breerly Feb 27, 2013

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

Is this even a real conversation?

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

This comment has been minimized.

Show comment
Hide comment
@ldath

ldath 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.

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

This comment has been minimized.

Show comment
Hide comment
@milesj

milesj 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 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.

@bobthecow

This comment has been minimized.

Show comment
Hide comment
@bobthecow

bobthecow Feb 27, 2013

Contributor

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

Contributor

bobthecow commented Feb 27, 2013

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

@ldath

This comment has been minimized.

Show comment
Hide comment
@ldath

ldath Feb 27, 2013

For Python PEP recommendations are official

Python - spaces - http://www.python.org/dev/peps/pep-0008/

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 ;)

ldath commented Feb 27, 2013

For Python PEP recommendations are official

Python - spaces - http://www.python.org/dev/peps/pep-0008/

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 ;)

@josegonzalez

This comment has been minimized.

Show comment
Hide comment
@josegonzalez

josegonzalez Feb 27, 2013

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

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

@ramcoelho

This comment has been minimized.

Show comment
Hide comment
@ramcoelho

ramcoelho Feb 27, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@ldath

ldath 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.

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

This comment has been minimized.

Show comment
Hide comment
@Crell

Crell Mar 1, 2013

Contributor

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 php.net 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.

Contributor

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 php.net 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.

@Vrtak-CZ Vrtak-CZ referenced this pull request in php-guidelines/standards Sep 5, 2014

Closed

Fix standards #2

@ionas

This comment has been minimized.

Show comment
Hide comment
@ionas

ionas 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).

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).

@php-fig php-fig 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.