Use tabs, not spaces

[fprochazka]

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

[foglcz]

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

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]

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]

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]

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]

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

[pmjones]

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

[vojtech-dobes]

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]

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

[Majkl578]

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

See also here: http://paul-m-jones.com/archives/2420

[Vrtak-CZ]

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

[pmjones]

A majority of the voting members disagreed with that position.

[milesj]

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]

indentation should not be part of standard

+1

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

[JanVoracek]

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]

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]

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]

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]

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

[pmjones]

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

[dg]

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

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

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]

+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]

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]

+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]

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.

[bobthecow]

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]

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]

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]

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]

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

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]

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]

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]

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

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

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

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

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

[HelloGrayson]

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.

• Python - spaces - http://www.python.org/dev/peps/pep-0008/
• Ruby - spaces - https://github.com/styleguide/ruby
• JavaScript - spaces - https://github.com/styleguide/javascript
• Coffee - spaces - https://github.com/polarmobile/coffeescript-style-guide
• CSS - spaces - https://github.com/styleguide/css
• Java - spaces - http://www.javaranch.com/style.jsp
• Scala - spaces - http://docs.scala-lang.org/style/indentation.html
• .NET - spaces - http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

[HelloGrayson]

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

Is this even a real conversation?

[ldath]

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]

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

[bobthecow]

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

[ldath]

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]

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

[ramcoelho]

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]

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]

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.

[ionas]

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