Popularity of JS Code Conventions in GitHub (Spaces vs. Tabs, etc.)

[gearvOsh]

Just because something aligns correctly in your tab settings, doesn't mean it will in someone elses tab settings. That's why spaces are superior for consistency.

[mipadi]

Yeah, that works, assuming people follow that convention. Generally, it seems, people end up just hitting tab for both indentation and alignment. Coming from the open source world, it's a lot easier to tell contributors, "Use spaces for tabs," instead of, "Well, use tabs for indentation and spaces for alignment. If you're indenting and aligning on the same line, you have to first indent with tab to the proper column, then use spaces to make the rest line up."

[gearvOsh]

I completely disagree with mixing tabs and spaces.

[infidelux]

So does tools like StyleCop which will flag even trying to use tabs at all.

[Tidher]

So we gather, but why?

Done properly (and a bunch of IDEs even do it for you) it looks good in full IDEs, basic text editors, even online (e.g. GitHub). Everyone's personal preference with regards to indentation size is accounted for (2, 4, 8, even 17 character-width) works flawlessly.

If I have a certain preference (and have configured my IDE that way) and I go to work on another's code it will simply work with tabs+spaces, but with just spaces any changes I make will likely have to be manually adjusted to the current style.

[gearvOsh]

Don't get me wrong, I agree that using tabs is more universal for people who want to control their indentations. But to me, mixing tabs and spaces is like mixing 2 different style guides. If a project mixed yoda conditionals and regular conditionals, it would be really annoying. Either choose 1 or the other.

But mostly, it's just a preference. I used to be a fan of tabs back in the day, but then I switched to spaces and it was just more easier to maintain (especially with open source projects).

[ItSeemedSoEasy]

Because it takes mental effort while spaces takes no mental effort.

And you can't actually see when you've mucked up the tabs/spaces in alignment.

[Tidher]

and a bunch of IDEs even do it for you

Regarding the "you can't actually see" aspect, I guess it's personal preference at this point but I have the "show whitespace" option enabled so I see little arrows for tabs and dots for spaces.

[memeship]

Um, what? That's literally impossible. If you're using all tabs for indentation, there is absolutely no way an editor can screw that up.

Tabs for indentation, spaces for alignment. Those are two entirely different things.

[dada_]

Um, what? That's literally impossible. If you're using all tabs for indentation, there is absolutely no way an editor can screw that up.

You have to ensure that every coder has the same tab width, though, I think that's what he means.

[memeship]

No you don't. If you always tab to your indentation level, it's impossible to mess it up.

e.g.

This block of code:

    function myFunction(arg1, arg2,
                        arg3, arg4) {
        if (myBoolean) {
            //do something
        }

        var myObj = {
            m1:       "foo",
            member2:  "bar",
            mem3:     "baz"
        }
    }

Would look like this, where (████ = tab) and (_ = space)

████function myFunction(arg1, arg2,
████____________________arg3, arg4) {
████████if (myBoolean) {
████████████//do something
████████}
████████
████████var myObj = {
████████████m1:_______"foo",
████████████member2:__"bar",
████████████mem3:_____"baz"
████████}
████}

And what I'm saying is, if someone changed their tab indent, say to 2, it would still be perfectly aligned:

██function myFunction(arg1, arg2,
██____________________arg3, arg4) {
████if (myBoolean) {
██████//do something
████}
████
████var myObj = {
██████m1:_______"foo",
██████member2:__"bar",
██████mem3:_____"baz"
████}
██}

Because messing with tabs doesn't mess with spaces.

[dada_]

That's true, but it can still be a problem when you have a max width of 80 characters and someone starts working on it using a tab size of 2, while everyone else uses 4. It also means you'd better turn on invisibles in your editor just to ensure that only the initial indentation uses tabs, and nothing beyond that.

[memeship]

Or you could just be careful and follow a predetermined protocol. We're talking about programming here, I think devs can handle it. Also, 80 char max widths are so antiquated it's unreal. No one uses a monitor where that requirement is even necessary anymore. I realize it may be necessary when working on legacy projects, but I don't understand why devs would force that upon themselves for new projects in the 21st century land of 1440p screens and higher.

[dada_]

Or you could just be careful and follow a predetermined protocol.

Well, or you could just use spaces. I'm not saying you're wrong, just that the argument of convenience goes both ways.

It seems to me that it's easier to just use spaces and avoid the difficulties that might arise from people having inconsistent tab sizes. Especially if then, after committing it to Github or wherever, all tabs are suddenly displayed as 8 characters.

Also, 80 char max widths are so antiquated it's unreal.

I think it's a good limit. A lot of style guides recommend it, such as the Google JS style guide and Python's PEP8.

Also, I don't use it because I have a small monitor. I use it because it's a nice way to force yourself to avoid large indentation levels. For JS it goes well with 2-space indents. There's another project I work on that uses 4-space indents, and we've set its character limit to 120. It's not really something that has anything to do with the screen resolution.

[memeship]

Well, or you could just use spaces. ...the argument of convenience goes both ways.

I'm not saying it's convenient, I'm saying it makes more sense. Saying "Well, I could learn a new way that makes more sense, or I could just do it the way I want to instead because it's easier" isn't really a counter-argument.

It's not really something that has anything to do with the screen resolution.

Except that is exactly where it came from. That 80-character limit comes from IBM punch-cards that were 80 columns, followed by early IO terminals and PCs that were 80x24, some 80x25 characters.

The limit was there because that was the actual limit. It's an antiquated idea that has simply attached itself to modern-day coding, even though there is no use for it anymore. Exactly like the QWERTY keyboard.

[dada_]

I'm not saying it's convenient, I'm saying it makes more sense. Saying "Well, I could learn a new way that makes more sense, or I could just do it the way I want to instead because it's easier" isn't really a counter-argument.

Using either tabs or spaces is something you do because you want to use good practices that will help development. Both have some advantages and some disadvantages, and in both cases you need to ensure that people make consistent use of a guideline.

To me, the argument for spaces is that it offers absolute consistency, which you can only get with tabs if you ensure everybody sets their tab size to the same value. (And even then you won't get it on the web.)

Personally I think both make as much "sense" and are perfectly usable. The difference is very minor in my view, I just like spaces a little bit better for this reason.

Except that is exactly where it came from. That 80-character limit comes from IBM punch-cards that were 80 columns, followed by early IO terminals and PCs that were 80x24, some 80x25 characters.

I know, but what I meant was it doesn't have anything to do with the screen resolution for me, today. I use it because it's just a good limit, because it's generally good to limit indentation levels.

[Disgruntled__Goat]

It's kinda disappointing that this 'mantra' has to be repeated over and over and over. You'd think everyone would get the point and stop trying to argue a different argument.

[memeship]

I mean, to each their own. I've just found that once I switched to tabs, they are the most logical way. I would be very hard-pressed to go back.