[erlang-questions] Controversial subject of the day: tabs and spaces for indentation

Bengt Kleberg <>
Thu Feb 6 08:36:15 CET 2014


These are opinions, not facts.

Go is a cool language in many places. This is one place.

The use of one tab for one level of indention is logical. The indention
level is 1, so why have another amount of characters? The only reason I
have heard for X =/= 1 is that 1 space is too narrow. So, use 1 tab. All
editors that I use can make 1 tab take up whatever width I like for


 On Wed, 2014-02-05 at 14:46 -0600, Mark Allen wrote:
> The golang "go fmt" command parses the programmatic AST and returns human
> readable text formatted to a configurable style sheet.  They also have "go
> fix" which parses the AST and dynamically replaces opcodes/sequences with
> upgraded opcodes/sequences when moving from version 1.X.X -> 1.X.Y
> It's kind of cool, but the pre-defined golang style is tabs only for
> indentation (no spaces) which drives me insane, but at least its
> consistent.
> Mark
> On 2/5/14 2:28 PM, "Garrett Smith" <> wrote:
> >On Wed, Feb 5, 2014 at 2:21 PM, kraythe . <> wrote:
> >> Actually the solution to this age old debate was proposed to me by a
> >>friend
> >> of mine and its genius on a number of levels but isn't implemented
> >>anywhere.
> >> The reality is that for most languages whitespace is irrelevant so it
> >> shouldn't be the code holding the indentation but the user's preference
> >> file. Imagine a source code repository where there is NO irrelevant
> >> whitespace in the code base. For java, for example, there would be
> >>literally
> >> only one single line of code. Now when you check out you have a
> >>preference
> >> file that says you want tabs or spaces or mixed and also defines the
> >>other
> >> formatting you prefer. When you check out the system reformats the code
> >> according to your specs dynamically. When you commit, it strips your
> >>code of
> >> whitespace before comparing.
> >>
> >> Now that would rock. Not just for tabs but the other code holy wars like
> >> drop braces and so onl
> >
> >Heh, not bad. I wonder how something like this might evolve.
> >
> >Garrett
> >_______________________________________________
> >erlang-questions mailing list
> >
> >http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list