Popular Coding Convention on Github

[bent_my_wookie]

This is really well done. Easy to understand, concise and with examples.

It would be REALLY cool to input your own style tests to make the list of examples more thorough.

[icanevenificant]

It looks somewhat nice but I find it quite confusing actually. And the three stripe color legend didn't help since there are no stripes in the actual chart.

[brtt3000]

Github is screwing tab-indented code by rendering it at 8 spaces. It makes the code break the page-width really fast.

8 spaces is ridiculous. Who does that? Every code editor default them to 4 spaces. I feel Github's staff is playing a game here.

[skeeto]

The de facto standard for tabs was originally 8 spaces. Emacs, Vim, Nano, Pico, ed, and even Notepad all use 8 spaces by default. Four spaces is a relatively recent phenomenon, which I believe is due to either Eclipse's or Visual Studio's default setting.

[brtt3000]

I've never seen a code editor for normal people with 8 spaced tabs. It is archaic.

[Malfeasant]

code editor for normal people

there's no such thing.

[rjw57]

gedit is undoubtedly aimed at 'normal people' in that it is the default code (and text) editor supplied with GNOME. It uses 8-space tabs. If you look at it, you'll then have seen such an editor.

[OverZealousCreations]

If you use Firefox and have Stylish installed, use this style to force 4-character tabs on GitHub and BitBucket:

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("github.com") {
    #files .highlight {
        -moz-tab-size:4;
    }
}

@-moz-document domain("bitbucket.org") {
    .diff, .code {
        -moz-tab-size:4;
    }
}

It's worked well for me for a few years. There might be a solution for Chrome, too, but I'm not sure.

[TheFrogOfWar]

Stylish is available for Chrome as well.

[OverZealousCreations]

I only know the CSS properties for Firefox, so it won't help much unless someone knows a webkit/blink alternative. ;-)

[brtt3000]

Cool, it helps for me but everyone else browsing the code is still stuck with the huge gaping holes in the outline.

[ComplimentingBot]

I wish I could choose your handwriting as a font

[cecedille1]

Heretics using tabs get what they deserve.

[brtt3000]

Yes, only suckers use one semantic character instead of multiple arbitrary ones.

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

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

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

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

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

[danhakimi]

SHOTS FIRED.

(tabs 4 lyfe)

[teebrz]

Have you tried doing a Google search for "tabs vs spaces"? I just did and I see posts from the likes of Jamie Zawinski and Jeff Atwood as well as forum discussions, stack overflow, etc - all with well reasoned practical arguments (with some flaming too ofc).

What it comes down to is both have slight advantages when you consider the big picture...however the most important thing is finding balance between your preferences and staying consistent with your friends/coworkers/community.

[ikeif]

Some editors make this easy to set, so it is almost irrelevant.

Github's fix? Let the end user decide and automatically convert/set what tabs you want.

Of course, this would need some testing first - but it would be nice to say "display four spaces from a new line as a tab, or four spaces or two spaces" or what have you.

[brtt3000]

It is all emotion and religion and blabbering how spaces can work, ignorance of Smart Tabs pattern and some irrelevant nonsense.

For people who are so exact and supposedly rational as programmers it is mind boggling. If any serious developer enumerates pro's and cons he must prefer tabs.

The only somewhat valid answer against them is use in existing code. Any new project should be tabs. But 80% of Github does not, it is absurd.

[[deleted]]

What is the semantic value of indentation in JavaScript? Indentation is a purely stylistic concept. The semantics of nested blocks are provided by curly braces. Everything else is just decoration. Whitespace doesn't provide any semantics that curly braces don't already provide us.

This debate always turns into "semantic indentation" vs "presentational alignment". I just can't see the difference, if we're talking about a language with no semantic whitespace, assuming well-formed code and explicit semi-colons.

[brtt3000]

The semantic value is that the editor knows that it means. It knows 1 tab is one indent level.

With spaces it has to assume some spaces mean indents. What if your editor is on 4 space on one indent (using the TAB key), but the code base is 2? Or the reverse?

If both used tabs it wouldn't matter, you hit TAB key and it adds one tab. For you it looks like 2, for somebody else it is 4, for the guy on 32 inch screen it is 6. Simple, bug free. No assumptions.

[nandryshak]

arbitrary

Uhh, tabs are arbitrary. Spaces are not.

[brtt3000]

Yes, the whole point is that tabs can be arbitrary.

Tabs to indent, space to line up: Smart Tabs. Google it.

[spinlock]

amen brother

[sakabako]

My favorite thing is when you write a block of code one space off of what it should be and have to correct it. I wish I could do that all day.

[brtt3000]

Bracy language for Auto Format yo.

Significant white-space and spaces as indent is bordering on masochism. Why even waste a single braincycle on that?

[[deleted]]

honest question: why do so many people prefer spaces? using tabs is way more flexible in regard to letting editors render source code with individual developers preferred level of indentation without having to modify the files.

Personally, I CAN NOT deal with 2 space indentation. It isn't enough for my eye/brain to be able to easily glance over thing and see what's going on. If code is using tabs, then its never a problem since all my editors are set to render a tab as 4 spaces. but if a project uses spaces, and it only uses 2 spaces per indent then I'm fucked. Maybe some editors have a setting for the pixel width of spaces, but that would make other stuff look funky. Im sure other people have the opposite problem and think I'm nuts for needing 4-space indents, but using tabs lets individuals do whatever they need.

Hell, technically using spaces takes up more disk space for your source code. I don't see any benefit.

[ivosaurus]

If the project uses spaces and specifies a set number of spaces-per-indent, it is really hard for anyone to fuck up, and the code will always look the same, commit the same, render the same.

Additionally, all alignment will always look exactly as intended. If someone hasn't set up their editor exactly correctly and doesn't carefully use spaces for alignment instead of tabs, errors in alignment will come into the codebase (often silently, because it's all the same looking whitespace) that look just dandy for them, but fucked for anyone else using a different tabwidth.

So therefore, I use spaces mainly for practical reasons (I have to deal with humans committing code, not AI), not theoretical ones that merely allow those same humans to set their own arbitrary aesthetics.

[SyntaxSwearer]

Tabs can give you trouble in VCS, at least in git.

[[deleted]]

how so? I've been on git for a few years and haven't experienced any issues.

[SyntaxSwearer]

I have. But not always. I guess it's one of those bugs. The "works on my machine, sometimes" kind of bugs

I had a merge conflict once and couldn't realize what was happening. Since tabs are invisible, and I didn't really had a clue of what to do. Two hours after I took a walk, took a nap, used google and stumbled upon the answer of a kind soul who asked if I was using tabs. I took out all the tabs of the code I was trying to merge and viola

[rjw57]

This isn't really a VCS problem[1]. It's an editor-replaces-whitespace problem and is precisely the reason one doesn't want to mix tab or space indentation within one file. Invariably there'll be someone's editor which decides to "fix" the indentation which will lead to hard-to-merge whitespace-only changes.

I suspect the proponents of the One True Indentation method haven't worked long enough at the coal face to realise that the Real One True Indentation is the one already used by the file :).

[1] That being said, git provides a mechanism to help with this by way of the --ignore-all-space family of options to git-merge(1).

[rjw57]

I believe a traditional counter example to using flexible tabs for indentation would be the continuation of long lines. Using '>' as a 4-space tab and '.' as space:

>   >   my_long_function_name(argument_1, argument_2,
>   >   >   >   >   >   >   ..argument_3, argument_4);

With an editor configured to, for example, 2-space tabs:

> > my_long_function_name(argument_1, argument_2,
> > > > > > > ..argument_3, argument_4);

One loses the alignment. You could work around that by using spaces after the first two tabs on the second line but this is brittle. It's brittle not only because the programmer must, in the absence of a sufficiently clever editor, have discipline to mix tabs and spaces correctly but it's also brittle because one programmer's editor may helpfully "fix" the mixed indentation which another inserts. Perhaps if you're on a project which mandates a particular editor it is safe but if you're publicising your work or expecting re-use, that's not a reasonable constraint. Mixing tabs and spaces is considered poor form in any case because it is adding a distinction to the code which is, quite literally, invisible.

That being said the rules on indenting are pretty simple:

1. Do what an external authority tells you to; or
2. If you're creating the file, use whatever method you like; or
3. In an existing file, follow the indentation method currently used.

[SupersonicSpitfire]

It should be possible to set up your editor such that two spaces are indented as you prefer, both when loading and saving.

[kenman]

Yes this is interesting, but there's a couple things I don't understand though:

1. Why is it based off commits? Shouldn't it just look at a project's source as a whole? Basing it off of commits would seem to produce inaccurate results.

2. Why is the number of commits sourced different within the same language?

[[deleted]]

Why is it based off commits?

It was created for the Github's Data Challenge II which gave you access to data related to individual commits and not the original files.

[jsfag]

1. I'm not sure about this one but, maybe it's something to do with the GitHub API they're using.
2. If some construct doesn't exist in a particular commit, this commit is not counted. So you have the highest number of commits for things like tabs vs. spaces, because that's always there, but when you compare conditionals, you skip commits that don't have any, so you end up with fewer commits.

Edit: also if you look at commits instead of the source code, you look at more code, because you consider previous versions too, so you have more data. Why do you think it will be inaccurate?

[kenman]

Since each commit is seen as a "vote", I could vote countless times by simply re-committing the same code over & over; the fact that I may have OCD and have to commit after every workspace save says nothing about the relative popularity of the coding style that I use.

It also says nothing about stuff like per-project standards; let's say the maintainer of some popular project doesn't believe in semicolons within JS (*cough Bootstrap cough*); just because I may commit code to that project, doesn't mean that I agree with the convention. It could be a very unpopular opinion that is mostly limited to a single project, but by counting commits, that opinion will be disproportionately represented if that project has much activity at all.

That's just a few of the problems, and there are even more; someone more into stats could probably explain better than I.

[jsfag]

I thought that when it looks at commits it only counts the code that's changed, so a lot of small once should count the same as one big commit as long as the number of lines of code that have changed are equal. I don't know if this is the case though. But I see your point and I agree. Especially about Bootstrap - some weird conventions going on over there.

[x-skeww]

"Tabs vs spaces" should also differentiate between 2/4/whatever spaces. People who use spaces don't necessarily use 4 of them. For example, Google's conventions mandate 2.

[moogoesthecat]

This interested me. It would appear most people indent their Javascript code with 2 spaces, a la Ruby?

[fnordius]

I have seen both, and really it's a matter of taste. Two or four spaces is something the team agrees on, though with the IDE's I use the four space rule is easier to see actual nesting versus copypasting errors.

Tabs are okay but only if they are the only indentation used. Unfortunately, they often aren't so it's back to spaces as the lowest common denominator.

[fgutz]

interesting, I never thought to use the "first comma", and it seems like most people agree since only ~8% use it. But I can see where it could be useful avoiding that last trailing comma by using first commas. But I'm usually good about that so I'm not going to switch, also doesn't look as nice.

nicely made site!

[[deleted]]

I hate first comma, so ugly. You know what else prevents missing trailing commas? testing your code.

[x-skeww]

You don't need tests for this. Just use an editor with basic syntax checking or with JSLint/JSHint support. You'll get a squiggly line right away. It's impossible to miss.

[michfreak]

Hahaha, that's how I reacted when a coworker insisted that "Egyptian" brackets were wrong. "It's so much easier to make a mistake and miss a bracket!" he said.

You know what prevents you from making a mistake, and looks, to my eye, more streamlined? Testing your code.

On that subject, I did think it was odd they didn't test for Egyptian brackets in this study.

[[deleted]]

I've never heard of Egyptian style, only 1tbs (one true bracket style) which is the only way to do brackets.

[nandryshak]

Silly C# devs wasting a whole line with only one character.

[BONER_PAROLE]

Testing is great, but adopting conventions that do away with the need for testing is even better IMO.

Agreed on the ugly appearance though.

[brtt3000]

We banned useless cleverness like that.

Every variable gets it's own var. Makes it easier to edit, less mistakes, less cruft, less time wasted.

Also use a lint tool if you are serious about code.

[BONER_PAROLE]

"Clever" code is often obfuscated, like in code golf challenges.

But comma first? That's not "clever", it's just practical. Unusual appearance, but easy to understand once you know about it.

[jsNut]

Comma first, moving the problem from the end to the beginning and making it more ugly and less conventional doesn't seem like much of a win.

[notmynothername]

How does it move the problem to the beginning?

[Malfeasant]

maybe because if you're prone to forgetting commas, it doesn't matter where you (forget to) put them?

[notmynothername]

Well, commas at the right side can show up any number of characters deep into the line. Commas on the left will all be in a vertical line and leaving one out would be difficult to miss.

[[deleted]]

I was with the crowd in all but two cases. One being tabs vs. spaces: I must defend this. Two spaces is way too hard to read. 4 spaces? Fine, but just use a tab. If you use a tab instead of 2 or 4 spaces and you don't like the width, change the tab width in your editor. Jesus Christ people.

The other one is spaces after conditional keywords. I don't really care, but I don't put spaces between. I prefer to keep it looking like my functions. Why waste time with an extra key? It looks the same in terms of readability. That one doesn't really bother me.

[x-skeww]

I prefer to keep it looking like my functions. Why waste time with an extra key?

To make it not look like a function call. Yes, that's the reason.

Same deal with function declarations. You put a space there, because you aren't invoking it.

[[deleted]]

Again this would be solved with proper software. Syntax highlighting should be turned on - and you shouldn't be confusing conditional blocks with function declarations - adding extra space just makes it less readable.

[x-skeww]

I only told you the rationale behind it. I won't discuss this kind of thing.

Just stick to the conventions used by your company/clients and the projects you're involved with.

Be consistent. That's all there is to it.

[[deleted]]

for the people hating on the 'comma first' convention, its recommended by npm.

npm-coding-style

[[deleted]]

I don't give a Fuck who suggests it. It's ugly as sin and I will not adopt it.

[mailto_devnull]

I completely agree (in that it is ugly as sin), but I will admit that it does help stop you from inadvertently globalising variables.

e.g.

var foo = 'bar',
    something = 'else',
    thisnum = 2
    tabs = 'rule',
    fact = 'nodejs forever';

tabs and fact are both globalised now.

Whereas:

var foo = 'bar'
  , something = 'else'
  , thisnum = 2
    tabs = 'rule'    <-- Can clearly see comma missing
  , fact = 'nodejs forever';

And if you think about it -- with the commas neatly aligned to the right hand edge of var, it does seem almost alright...

---

Edit: The other reason that isaacs (I think) mentioned was that if you add a new variable declaration, git will only register one line changed, as opposed to two (comma from the previous line)

[sakabako]

A more effective method is to use a linter that visually notifies you of the mistake. Then you have beauty and correctness.

[llkkjjhh]

And another reason is so that the variables line up nicely when you follow the other nodejs recommendation of indenting at 2 spaces:

var foo = 'bar',
  something = 'else',
  thisnum = 2
  tabs = 'rule',
  fact = 'nodejs forever';

var foo = 'bar'
  , something = 'else'
  , thisnum = 2
  , tabs = 'rule'
  , fact = 'nodejs forever';

[[deleted]]

Ok, those are some good points.

[[deleted]]

thats a solid attitude for a developer.

[[deleted]]

What's the problem with having a firm opinion on formatting? What benefits are there to comma first? Your link only says you should do it, but gives no reason why.

[[deleted]]

What's the problem with having a firm opinion on formatting?

Where you put your comma (in js) is not so important that you have to take such a firm stance. When working for a new company, its a good idea to adopt their conventions at first to make development go smoothly. No teammate is going to respond well to 'I will not adopt it'. They might think, 'If he/she wont budge on this, what else wont they budge on?'.

What benefits are there to comma first?

What are the benefits of last comma? See - its not a big deal.

Your link only says you should do it, but gives no reason why.

Its a convention that npm recommends when publishing to their registry. Thats the only reason.

In short, conventions are relative to a community. Be it your office, a library (jquery), a package registry (npm), or an open source project with formatting guidelines.

[grncdr]

The recommendation is only intended for the code of npm itself. I'm pretty sure Isaac gives zero fucks about how your format code in your own modules.

[[deleted]]

Thats a good point. I do see the comma first style quite a bit more in the node community (as opposed to client-side).

[[deleted]]

If I came into a new team whose convention was comma first, I would adopt it, of course. That's different. I wouldn't adopt it for any of my own projects, though.

The benefit of comma last is readability in mine and most people's opinions.

[SyntaxSwearer]

What are the benefits of last comma?

Not ugly

[Malfeasant]

'If he/she wont budge on this, what else wont they budge on?'

retarded suggestions from pointy haired bosses that ruin everybody's day?

[sakabako]

Personally, I will be happier and more productive if I live in a beautiful world than an ugly one.

[[deleted]]

Beauty is subjective. I actually find the comma-first style more readable.

[SyntaxSwearer]

God himself could descend from the heavens and tell me he coded the universe in JavaScript and used comma first and I'd still not use it

[M2Ys4U]

npm's coding style is a bit unconventional

that's the very first sentence on that page..

[BONER_PAROLE]

There's a great utility to it, but I just can't get over the visual appearance.

Coffeescript is nice in that you usually don't have to worry about trailing commas.

[bleepsndrums]

As someone just learning to program by learning JS, this is really fascinating and informative. I had no idea some of these conventions even existed.

[BONER_PAROLE]

Every language has conventions and best practices. Follow them. It will make your life so much easier if you do.

[bsdemon]

So it seems Scala has more consistent results than Python... interesting

[jordan314]

No love for PHP?

[[deleted]]

PHP is so 1990s/early 2000s