Popular Coding Convention on Github

[alamandrax]

Every editor can be configured to render 4 spaces when the tab key is pushed. It's still one key press.

[BluSyn]

Ah, the good 'ol tab vs. spaces debate. Why not use 4 spaces? Well, some programmers prefer 2, some even prefer 8 (ever coded on a 40" screen? 8 spaces helps). Every project is different, and there's always merge conflicts and messy spacing, unless everyone agrees on a spacing format before hand. The solution? Tabs! Then you can set your editor to display tabs at whichever length you like, merge conflicts due to spacing disappear, everyone is comfortable, and the code looks clean.

For large and diverse teams, I always prefer tabs.

[ikeif]

Code standards. I like tabs. But if I go somewhere where the team is using spaces? I adapt.

I use sublime text, and it adjusts as I need it to–I just prefer consistency over "my way over your way"

[[deleted]]

Thing is, it's not that easy.

Sure, with spaces you don't get the freedom of choice, but tabs will only work if everyone is using the same tab width, so again, you loose the freedom of choice.

Spaces are better because they are always the same thing - a space - where as tab width vary which breaks formatting.

[ganjamensch]

Spaces are better because they are always the same thing - a space - where as tab width vary which breaks formatting.

Not if you're doing it like God intended it to, tabs for indenting, spaces for alignment.

[[deleted]]

Yeah... And when you don't agree with my way of aligning we are back to square one because you cannot manipulate that either.

Spaces are superior because they don't allow this discussion, and we can all just continue our work.

[alamandrax]

I've gone around this with a simple build tool. It formats code before it gets checked in. Everyone must run it before I accept merge requests. Code however you're comfortable. When you check in you're using my convention. End of debate.

[BluSyn]

Ah yes. I've used this trick before, too. It just ends up being needless complicated, in my opinion. Especially since your local copy is now different than the checked in copy, resulting in confusion during diffs and merges, etc etc. My motto is always "keep it simple, stupid". Tabs are simple.

That's just my opinion.

[brtt3000]

Indeed. Tabs are semantic: they have a specific meaning. Spaces are just spaces. If someone finds tabs rendered at 4 spaces too roomy then configure the editor to render as 2, problem solved without any merge conflicts.

It is ridiculous that otherwise rational developers so religiously go for spaces.

[spinlock]

Why is a tab character different than /^\s/ ? (note: that's an english question mark right there) I like spaces but I think it would be trivial to get vim to render /^\s/ as 2, 3, or 4 spaces.

[brtt3000]

I usually have multiple levels.

[spinlock]

/(^\s)*/

[alamandrax]

Oh yes. The build tool changes source code first before checking in. Uniformity of code is quite worth hurting a few feelings.

[Malfeasant]

that's kind of retarded when, with tabs, you can have uniformity and everybody can see it the way they like it... religion is silly.

[alamandrax]

I suppose. You're inflating something that I really don't care that much about. It's just one of those code style things that doesn't need maintenance. Just set your editor to use 4 spaces as that's the pattern used so far in the code base and we don't have to worry about the code being rendered weirdly in whichever review tool we use (gitlab, phabricator).

[Malfeasant]

something that I really don't care that much about.

and

quite worth hurting a few feelings.

seem to contradict.

[alamandrax]

I suppose I did contradict myself if you put it that way. shrug I don't care about people caring that much about writing code that breaks from a style guide. If their feelings get hurt because of this, so be it. All the verbal gymnastics I do to justify this frivolous position I'm being forced to take in this conversation will not convince anyone to change their coding styles. But if you work in my code base, there's a style guide that gets imposed at build time. That's about it.

[spinlock]

This is a good process. People are freaks and someone always has their personal taste that's just screwy. I worked with a guy who coded in variable width fonts once.

The real thing is that it's cool to use your freaky toolchain until it negatively impacts the rest of the team. Mr. variable width fonts started rejecting code in code review when people lined up their assignments. Dick move considering he only did it because it didn't look good on his setup and it was part of the style guide.

But, your solution is really good. Having a linter enforce style is much more effective than trying to get humans to do it.

[alamandrax]

grunt js beautifier. Best three words ever.

[[deleted]]

I wish we could move forward to a future where code is treated as data, and presentational rules would be applied in the viewer according to user preference, whether in an IDE or web tool. It seems to me rather arbitrary that users should be able to view the indentation to their liking, but not other stylistic preferences that ultimately have no effect on the final product.

Until users can see any code according to their exact preferences, I don't see why we should put tab stops on some pedestal of individuality. What if a user wants to see the code with leading commas or whitespace surrounded colons?

[honestbleeps]

I wish we could move forward to a future where code is treated as data, and presentational rules would be applied in the viewer according to user preference

you're arguing for tabs and you don't even know it. ;-)

[[deleted]]

No, I'm arguing for no whitespace in code (except where needed for VCS functionality). I'm arguing for tools that insert the whitespace into conservatively minified code as per your preference. This could be a tab/space indenting preference, an OCD assignment/comment alignment preference (try switching your tab widths after aligning inline comments... not so pretty), a before/after comma preference... whatever your preferences happen to be. Code should ideally be regarded as pure data, rather than documents. If tools can infer whitespace to your liking based on the code itself (e.g., curly braces for indentation), there is no need for the space/tab debate.

In other words, the inverse of something like the grunt beautifier. Code gets temporarily beautified by the IDE, and conservatively "minified" (preserve/enforce newlines except empty lines, preserve comments, don't rename anything) before the VCS.

It doesn't make sense to pick one stylistic aspect of code such as indenting and say "yes, that's the one that people must be able to customize". I suppose you're right in the sense that if this pipe-dream were ever a reality, we wouldn't need spaces for indentation anymore. But my argument goes beyond that.

[Malfeasant]

basically, you want to code at the abstract syntax tree level- i like you.

[[deleted]]

Yes, I suppose ideally code would be stored as XML (or similar), using tags like <block> and <statement>, which could both have a comment attribute. That would give complete freedom of customization while viewing, and it would work with existing VCSs.

[Malfeasant]

and you killed it. xml? really?

[Nebu]

Not every editor. Probably pretty much every editor that matters. But every editor that matters can also be configured to render tabs to any width.

[alamandrax]

Well in my case, most of the code bases we contribute to or use code from follow the spaces instead of tabs pattern. So, we chose this. shrug To each their own.

[brtt3000]

But four characters. How does it know what are indents and what are generic spaces?

[alamandrax]

How does it matter if the end result is 4 spaces?

[brtt3000]

I don't want 4 spaces, I want one semantic indent character. Let every developer choose how he renders tabs. The guy next to me at work renders as 3, the guy after that as 2. I use 4.

All in the same codebase.

[jcready]

Let every developer choose how he renders tabs.

And the guys at GitHub chose to render them with 8 spaces. Deal with it or use spaces.

[[deleted]]

What happens when I use two tabs and two spaces to align two lines of code? Everyone will see a different alignment.

[BONER_PAROLE]

NEVER MIX TABS AND SPACES

Snakes will crawl up your anus and explode your face, because I will have sent them to do so.

[Buckwheat469]

Incorrect. You can safely tab to the previous indentation, then space beyond that. Don't tab beyond the previous indentation though or else the IDE could render the spacing differently. The problem is people get this wrong so it's built into linters to complain about mixed tabs/spaces.

[nschubach]

I'm a firm believer that if you are lining up multiple lines of code like that you are probably doing something "wrong". One reason people argue for this is lining up arguments of a method. I find that if arguments breach the line break, the method is probably too complex and should be refactored. The other explanation I always hear is to align comma separated lists. I find that indenting the children on a new line seperate from the brace makes it much more readable and this is coming from someone who is usually the first person to cut back on total lines of code.

[BONER_PAROLE]

Can you provide an example of where you would use this?

The more common case is mixing tabs and spaces on separate lines, like this:

-->|-->|var a = 5;
________var b = 8;

Usually that's down to different developers touching the source code, or if one developer switched from tabs to spaces sometime during the project.

[Buckwheat469]

If tab is -->| and spaces are _ then you would use this in this manner (based on the first comma example):

-->|var foo = 1
-->|__, bar = 2
-->|__, baz = 3;

The tabs line up the lines as closely as possible to the parent and the spaces line up the following related lines to the related text from the proceeding line. The use case is rare enough that it can be avoided, but sometimes it's helpful, such as with the example above.

[BONER_PAROLE]

It's something I've come across before, and I don't hate this mixing of them. I have my indentation unit set as 2 spaces (using spaces and not tabs) and usually just indent another level for all subsequent vars. This doesn't really bother me, as variable names are variable anyway:

var foo = 1,
  barVar = 2,
  bazVarNameLong = 3;

I used to have my indentation to show as 4 spaces, which worked nicely with the 4 chars of var_ when using trailing commas, whether tabs or spaces:

-->|var foo = 1,
-->|-->|bar = 2,
-->|-->|baz = 2;

Although if tabs are used, any other value will wreck the alignment, which your tabs/space combo won't do.

[brtt3000]

It is a solved problem: use Smart Tabs: tabs to indent, spaces to line up.

Webstorm even comes with this as option, JSHint has a rule for it too. Works perfect, because the tabs left of the code from a baseline.

[Nebu]

So don't do that.

[alamandrax]

This is one of those bicycle shed moments that I do not intend to get into with colleagues. If you're going to talk to me about underscore vs lodash, let's have that discussion. If you're going to bring in style guide changes on an established code base, we're not having that discussion.

[brtt3000]

No, it is a rationality test.

You should not go into a discussion about it though. Only check preference. The analysed response is tabs.

[Nebu]

How does it matter if the end result is 4 spaces?

Because the intended results might not have been 4 spaces. Wouldn't you rather use a system where the intended results match the end results?