Gofmt No Longer Allows Spaces. Tabs Only

https://code.google.com/p/go/issues/detail?id=7101

by gmjosack • 12 years ago

47 54 12 years ago

code.google.com

erkose• 12 years ago

This is the oldest most persistent argument in programming.

nickporter• 12 years ago

I wonder if other professions have similar arguments.

nmb2• 12 years ago

I got into beekeeping recently, and it's like this, except applied to everything.

libria• 12 years ago

No, Fitz is not advocating tabs over spaces in coding. He is saying gofmt loses a large part of its purpose if it does not enforce a particular style, and the Go devs happen to prefer tabs.

It sounds like he's fine w/ anyone using a tool to format by spaces.

That said, this is quite un-newsworthy.

gmjosack4• 12 years ago

I'd say it's newsworthy to large Go shops that use spaces with gofmt and now have to change indentation in their repos. This isn't insignificant. Also it requires additional flags for things like blame/diff to ignore whitespace changes.

notatoad• 12 years ago

It seems like a pretty silly argument. As long as there's a standard defined, any competent text editor can handle it for you. Go now has a standard - use tabs instead of spaces - and so the debate is over for this language, everybody set your editors accordingly.

angersock2• 12 years ago

Who actually uses tabs instead of spaces? I'm genuinely curious--one of the first things pretty much any project I've ever been involved in has been the setting of tabs characters to become spaces, simply because all text editors are retarded in this regard. This is quite strange.

josegonzalez• 12 years ago

Unsure if trolling or not. It's quite easy to have your editor represent a tab character as "n spaces" - where n is the number of spaces you find pleasing. In fact, I can't recall a serious editor where this isn't the case.

What issues have you seen with regards to using tabs?

angersock2• 12 years ago

Often different editors on a project (hell, even between computers for the same user) may display the same file different ways, and you almost always end up with weird mixes of spaces/tabs when indenting things (especially if you're super picky like I can be and really, really care about things lining up).

Simply having the editor expand tabs (to whatever people agreed on, usually 4 for C/C++ that I've seen) and save spaces, always, makes life simpler.

EDIT:

See Grandpa Zawinski's post on same: http://www.jwz.org/doc/tabs-vs-spaces.html

Glyptodon• 12 years ago

I'm not sure if there's an "issue" with tabs, but I have to agree that I pretty much never come across tabs in any of the languages I use regularly and find it jarring when I do so despite the obvious theoretical benefit of flexible tab widths enabling user preference.

I can't come up with a particularly good reason for it, but I'm so used to spaces at this point that tabs feel very wrong.

If anyone else has a good explanation I'd love to hear it.

MBlume• 12 years ago

Grabbing some Clojure code because it's nearest to hand.

Look here: https://github.com/clojure/clojure/blob/master/src/clj/cloju...

I want the bindings being declared within that let to line up with one another. the first one immediately follows "(let [" so I need the rest to be indented six characters past where the let was originally indented. Six, not N times whatever the tab width happens to be in whichever editor someone's looking at the code in. This is the problem with tabs.

subsection1h• 12 years ago

What issues have you seen with regards to using tabs?

How does a team adopt a standard regarding line length if their code base uses tabs and the team members specify different tab widths in their editors?

In my experience, devs that prefer tabs over spaces have a tendency to be unconcerned about line lengths, and their lines of code can become annoyingly long.

For example, the most popular Go project at GitHub[1] is Docker. Docker's code base contains Go files with lines of code that are hundreds of columns wide.[2] Gross. ;-)

[1] https://github.com/search?l=Go&q=stars%3A%3E0&type=Repositor...

[2] https://github.com/dotcloud/docker/blob/master/api/client/co...

nmjohn• 12 years ago

This is a huge speculation based only on personal observations, but I'd guess people who got started coding in editors where a space was only a space, so I could indent with one keystroke, tab or with 4+, spaces.

These days I use spaces, because apparently that what is "correct" these days, but I still press tab. Sublime just turns it into spaces and displays the indent as a tab.

eximius• 12 years ago

I do. Tabs are universal. Three indentations? Three tabs. The same cannot be said for spaces. You have to agree upon the width and make sure everyone sticks to that width.

Now, with tabs, anyone may customize how the width is VIEWED, but the representation on disk is universal.

cmelbye• 12 years ago

Virtually every Go programmer does, at least.

Zarel• 12 years ago

My project, Pokémon Showdown (https://github.com/Zarel/Pokemon-Showdown) uses tabs, although it's not for any religious reasons, it's just what I was used to when I created the project. I suggested changing to spaces when I learned they were more popular, but my most opinionated coder preferred tabs so I kept it at tabs.

Tabs and spaces both have their respective advantages and disadvantages.

Advantages of tabs:

- you can choose your indentation width in most editors, so coders don't have to agree on indentation width (this is really the only major advantage)

- most very-basic editors that can't be configured, such as Notepad or the command-line directly, will default to having the tab key insert a tab character, which is easier to press than space N times (it's rare to edit code in such cases, though)

- slightly smaller file-size, although this is pretty irrelevant in modern times

Advantages of spaces:

- certain editors are dumb and will mangle tabs in various ways (for instance, converting "3 tabs for indentation, 9 spaces for alignment" into 5 tabs and 1 space)

- most file viewers that won't let you configure tab width (for instance, browsers, which is relevant to viewing code on GitHub) will have tab width set to 8 spaces, which is very awkward

- avoids the problem of some people accidentally using tab for alignment and then having alignment be messed up when coders have different tab width settings

- certain text fields, such as browser text boxes, will have the tab key focus the next input field instead of inserting a tab character, which makes inserting tab characters difficult sometimes (it's rare to edit code in such cases, though)

robin_reala• 12 years ago

You can style tab width in CSS though. If you want GitHub to have smaller tabs add tab-size: 2; to an appropriate selection in your site-specific CSS. I’m sure there are extensions that will do this for you. More info: https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size

beejiu• 12 years ago

Tabs for scope, spaces for alignment.

pbreit• 12 years ago

Go developers typically use tabs.

You should really try not to use the word "retarded" like this.

rossy• 12 years ago

Linux kernel uses tabs. I'm a fan of kernel-style, so I use it in my personal projects as well. It seems common in C projects, anyway.

https://www.kernel.org/doc/Documentation/CodingStyle

oelmekki2• 12 years ago

While I use 2 spaces in all my code because that's the winning convention in languages / frameworks I use, I've always felt tabs were a superior option, most notably because everyone can set tab width to what he likes, so you have a standard file with custom look and feel. I set my tab width to 2 chars ; if an other dev prefers to use 4 chars, there is no conflict.

The annoying part is that you can't set tab width in browser (afaik), which makes it painful reading code on, say, github, and being displayed an indent as the equivalent of 8 spaces. Browsers have to fix that.

So, to answer your question : I do not use tabs, but I would gladly do if offered the possibility.

WorldWideWayne• 12 years ago

Spaces make zero sense for indentation. Why would you want to use them instead of tabs, which were invented for indentation and make perfectly logical sense (3 indents, 3 tabs and editors can dynamically adjust the width of your tabs). You get none of that logic with spaces.

AYBABTME• 12 years ago

And what's great; no Go developer will notice.

mahyarm• 12 years ago

Their source control will notice.

teddyh2• 12 years ago

The right way to solve all this tabs/spaces indentation mess would be to use Elastic Tabstops¹.

1) http://nickgravgaard.com/elastictabstops/

f2f2• 12 years ago

gofmt already uses elastic tabstops.

teddyh2• 12 years ago

To quote [1]:

Not really. Elastic tabstops is about enabling variable width fonts to be used in text (and especially programming) while still lining up tabular columns. What gofmt does is to use spaces to align columns; a method described in http://nickgravgaard.com/elastictabstops/ as a "kludge".

1) https://groups.google.com/d/msg/golang-nuts/93t0LWvHrKM/y6oI...

gmjosack4• 12 years ago

I'm personally in the spaces camp but my favorite point in favor of tabs no one has mentioned is all of the bytes you're saving. In a large codebase you can save kilobytes to megabytes by switching from spaces to tabs. :)

notacoward• 12 years ago

Yes, I see the smiley, but I thought it would be fun to measure this effect anyway. I whipped up a small Python script to measure the potential savings, and ran it across the 450kLOC GlusterFS codebase. It reported 3.4MB of savings (both realized and potential because our code isn't as consistent as it could be). I'm generally in the spaces camp myself, and believe that 3.4MB just isn't worth worrying about any more (despite being worth ten of the floppies that were omnipresent even several years into my career), but it's still a surprisingly high number.

bingaling• 12 years ago

Did you take into account filesystem block size?

zak_mc_kracken• 12 years ago

I predict that this change will be reverted in a few months when the Go team realizes that code is read in a lot of different places, most of which never display hard tabs correctly.

mseepgood• 12 years ago

I've read a lot of Go code in many different places during the last years, all with tabs, and I did not have any problems.

silon3• 12 years ago

Browser <pre supports tabs and defaults to the value of 8 (as is standard), so that shouldn't be a problem.

ahoge2• 12 years ago

You can also change it to 4 (which is what most editors use by default) via `tab-size`:

https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size

maxk422• 12 years ago

What are the pros and cons of each?

divoxx• 12 years ago

Awesome. The only thing that really matters is to have a convention, and tabs has been the accepted convention in the Go community since forever.

Changing go fmt to enforce the convention is simply making sure that people write code the same and frees the developers from the tireless discussion about which one is better. That alone outweigh any disadvantage of choosing one or the other.

ahoge2• 12 years ago

I prefer tabs (tab-size: 4), but I prefer even more if everyone follows the same conventions.

Dart, for example, uses 2 spaces. When I write Dart code, I use 2 spaces.

And that's the end of that. As history has shown, there is absolutely no point in discussing this. There is no clear winner.

MetaCosm• 12 years ago

Yep. Asking a developer about style/formatting is an amazing filter if you have a lot of candidates... the answers I am looking for include "the language / platform standard", "the overwhelming most popular standard". The answers I have gotten have been nothing short of insane at times. I had a guy explain to me for almost 25 minutes why HIS system is UNIVERSALLY applicable to our code base, from C and C++ (multi platform) to Python to Makefiles...

Gofmt No Longer Allows Spaces. Tabs Only

Related Stories