Hacker News Reader

Comment by zobzu | Hacker News Reader

"Indent 2 spaces. No tabs." Well fuck it.

Thats the only coding style that remotely makes sense to me: https://www.kernel.org/doc/Documentation/CodingStyle

While I'm at it, half the justifications Google gives for the shell guide are inaccurate. Looks like a "overall people are used to this style so we're using it and we'll try to justify it without knowing why"

This is a much better guide:

http://devmanual.gentoo.org/tools-reference/bash/

Example: Gentoo's [[ ]] explanation actually makes sense.

View on HN

Thread's gotten too deep and wide to reply to everyone, so I'd like to vent right here at the top...

We have these machines that are meant to take the tedium out of our lives, let's USE THEM. Why do we not have tools that format things they way I like them? Who cares how the other team members like it? They can use the tool, too. Who cares how it's stored in your VCS? The tool should just be part of the workflow and format spaces/tabs the way I want them and maybe revert to a canonical format for committing to the repo.

Personally, I prefer tabs. I read code best when it's indented four spaces. But John wants to use two spaces in this code. And Ralph likes three. Holy Hell, don't make me wade through someone else's preferences to understand this codebase! Use tabs and people can set them the way they want. Yes, tabs are broken in many places (e.g. Objective-C methods can get so verbose that they need to wrap; convention is to wrap and align the colons; tabbing as far as possible and then spacing to fill breaks things when Ralph formats his tabs to three spaces; in this case, there is indeed a solution: tab to the start of the original line of code, and space to format from there ... but then the IDE has ideas of its own about what should be spaces and what should be tabs...)

Maybe you can read that code with only two spaces of indent, but I can't. I'm gonna need that reformatted to put a larger visual separation between scope changes or whatever required the indention. Rather than have this debate, a tool should be forged.

Disagree. Readability is not about 4 or 2 spaces, it is about strongly enforced convention that makes these typographic details literally disappear from the eyes of the readers. This effect is very noticeable in book publishing: if you ever notice the typography, the typographer failed at his task. It is the same in code, just file the rules and it will become your preferred guideline in no time.

And repeated experiences everywhere point to the fact that code text is already very hard to manage, very sensitive to alterations, misreading, etc. I'd rather remove layers and tools than add more.

Edit: obviously, readability is ask about convention when they are within the realm of sane acceptable conventions. And by everywhere I mean in teams where the loc count is above a few thousands.

Disagree with your disagree. There is a difference between the actual code and how the code is styled. It makes sense to have conventions on how to format a for statement but not where to add brackets - making them be on the same line or on their own line makes little difference to noticing bugs and is purely a stylistic preference.

So you mean that the where-the-brackets guidelines found in core FOSS mega-projects, big corps like Google, down to many github personal projects having their own "please follow the guides" in the readme, all of them are misguided, useless, wrong and even, let'y say it, plain stupid?

I, on my side, claim that guidelines are there for a reason, and should be followed.

This looks at it only from the context of the single dev's machine. I care more about the consistency of the source code that's checked into the repository and not getting false file diffs based on white space differences, and other formatting discrepancies. And for some reason, this seems harder than it should be.

I'd like to see a diff tool designed around this.

That wouldn't be hard at all. All you need to do is assign a default style and create the diffs in that style.

The hard part is creating a tool that can change between styles. Such a tool would need to be made for every language separately which is a pain. I've been wanting to try something like this for years but have never built up the courage.

This is part of the purpose of lint tools, and they exist for many languages. e.g. http://www.jslint.com/

Sorry, I think I misunderstood the comment I replied to. I thought he was saying it would be hard to do diffs if people restylized each file to their liking.

  > Use tabs and people can set them the way they want.

If members of a team set tabs the way they want, how do they limit line lengths to 80 columns, which is a requirement that's specified in the Linux kernel coding style that was linked to in the comment you replied to?

not an issue. by assuming it is two spaces.

it is still better to have to switch to 2 tabwidth before committing to check line length then to be forced to use 2 spaces forever.

How about lining things up? Take a long function call where you want to wrap the params:

    hello( world,
           solarsytem,
           universe
           ... );

You can't if you just use tabs - you would have to mix tabs and spaces.

Use

   hello(
     world,
     solarsytem,
     universe
   );

which doesn't require perfect line-up with the first entry, and is still clear to the reader what's going on.

this is how i code. 1st pass: func( ); 2nd pass: put in the args.

this ensures the closing paren immediately and makes it possible to comment out things that are inside the parens.

so thats the reason why people are set on using spaces? man :(

> Yes, tabs are broken in many places (e.g. Objective-C methods can get so verbose that they need to wrap; convention is to wrap and align the colons; tabbing as far as possible and then spacing to fill breaks things when Ralph formats his tabs to three spaces; in this case, there is indeed a solution: tab to the start of the original line of code, and space to format from there ... but then the IDE has ideas of its own about what should be spaces and what should be tabs...)

Which is the problem. If you think it's possible to make a tool to solve this, great - do it, I'll happily adopt your tool as a precommit hook and use tabs to indent everything (or go on using spaces - your tool would turn them into tabs, right?) But given that this problem has existed since the '70s and no-one has solved it, I'm inclined to think it's impossible. So I'll use spaces in the VCS, which means agreeing an indent width so that our diffs make sense (and I don't really care whether that's two or four, but it does need to be defined and adhered to across the team).

It really doesn't matter how many spaces or tabs, what's important is that all code and scripts are written in the same style, which greatly reduces time required to understand someone else's code. At Google, that's a norm.

It actually does, 2 spaces indents are hard to read, period.

you're getting used to it within few months.. (currently we have tabs though)

Is there any scientific/empirical proof on this? I indent 4 spaces, no tabs, but I would like to see the real rationale there, not just the PEP-8 "rules".

Zero spaces makes indentation harder to spot than infinity spaces.

Infinity spaces gives less space for code than zero.

Conclusion: use as wide an indentation as possible while still keeping enough space for the code itself.

Is there nothing to be said for consistency?

When I suggest using that algorithm to pick an indent size, I mean to use long-term averages to select a standard, not to indent every line as much as possible individually :P

There is this: "Program indentation and comprehensibility (1983) by R J Miara, J A Musselman, J A Navarro, B Shneiderman"

http://www.cs.umd.edu/~ben/papers/Miara1983Program.pdf

I'd classify it as an attempt rather than something decisive but whatever floats your boat.

p866:

  The level of indentation that seems to produce optimal 
  results in comprehension is between 2 and 4 spaces; as the 
  number of spaces increase, the comprehension level 
  decreases.

On the other hand, the sample program hard parts that were indented nine times (!) in places. It's an interesting read, but I'd not try to use it in a discussion.

Personally, I don't care; just pick one (hopefully one that matches what most people are using with that language, eg. 2 spaces for Ruby), and get on with it.

Yup, they seem to have used an overly indent-happy indentation scheme. Two separate indents: he 'begin' after the 'for' and for the block body is superfluous. This raises the concern that their results are biased towards smaller indents.

No. Indent space is just an opinion/preference/habit.

I prefer 2 space indents (tabs)

Yup. After a decade of programming, the only thing I care about is consistency. Even the weirdest code style people can come up with is just fine in a clean, consistent code base.

Mildly surprised to see people arguing for specific tab widths...

Agreed, consistency matters most. Regarding whether it matters whether tabs or spaces are used, I've come to realise that I cannot control the tab length when viewing code outside of my editor (obviously!). So, let's say we have a 80 char line length limit. If I set my tab size to be 2 spaces, the line length is obviously going to be different to someone who sets their tab size to be 4 spaces. Just having the option to control the size of tabs means tabs should never be used as it will result in inconsistencies across editing/viewing environments. Also, when viewing code online, generally you have a limited viewing area. If you're using tabs, the length of the lines are generally going to be very long, and it's very difficult to view the code. In conclusion, if you care about things like line lengths (you should), and if you care about keeping your code in a certain and consistent format, the only way to manage it is with spaces, imo.

I've always been conflicted on this. It's simply untrue that more than 3 levels of indentation indicates bad code. For example, HTML, XML, and JSON often benefit from deeper levels of indentation.

Tabs have the benefit of having a dynamic size, so I could simply adjust the tab width within my editor. Spaces also do not play as well with editors. Unfortunately, browsers offer no means to change the width of tabs, so it's impossible to properly display code using tabs. This is especially frustrating when reading the source of a page indented using tabs. It would be much easier to read with spaces, but not as easy to read as if I were able to set tab width.

HTML, XML, and JSON are document description formats. For most programming languages, more than 3 levels of indentation is a red flag.

While it's true of some languages, it's certainly not true of all of them. I'm not sure most is accurate either. JSON is a subset of JavaScript, so it stands to reason that JavaScript could have as many indentation levels as JSON without a loss of clarity. It also stands to reason that any language with hashes, dictionaries, etc could feasibly exceed 3 indentation levels without it being a red flag, particularly if those hashes are in a method that is already indented more than one or two levels.

Well, Torvalds said that about C where you have no indent at the class/namespace level. So I'd argue it can be a bit more for languages that have this (most of the popular ones), 4-5 I guess.

So for those three levels, do I have to count the object and method-level indents, or is it a rule for languages with unindented includes?

It's a pity that elastic tabstops never got any traction. it's a really nice idea: http://nickgravgaard.com/elastictabstops/

This looks horrible if I want the opening brace on the same line as the closing parens around function parameters, but still want the function parameters to be aligned, like this:

  int someCodeDemo ( [tab] int fred,
  [tab]                    int wilma) {
  [tab]                    return fred + wilma;
  }

I guess it needs some vertical space between blocks in order to distinguish them, hence why putting { on the next line works.

In my opinion, it also looks horrible with Lisp code (where I pretty much consider indentation a solved problem).

Edit: Oh god, how do I format this... Ah, there we go.

There is a Sublime Text plugin compatible with ST2 and ST3 which does this. https://sublime.wbond.net/packages/ElasticTabstops

The only problem I've noticed is that it muddies the undo stack.

Real men and women indent by prime numbers.

Sure they do, add this to your user styles:

pre { tab-size: 2; }

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

Thanks, I wasn't aware of this. Hopefully we'll begin to reach a point where tabs are used and sites like GitHub adjust tab-width according to the developer's preference.

On tabs vs. spaces, read the old classic: http://www.jwz.org/doc/tabs-vs-spaces.html

tldr; don't use tabs.

I read that piece many years ago and thought who cares, but I've later changed my editor to never use tabs. He's right.

Tabs are nice in theory, but in practice you end up with garbled code. It's better to train yourself to get used to seeing code bases formatted slightly differently, just one of the things you have to get over, IMHO. Like camel notation version underscores versus dashes.

> It's better to train yourself to get used to seeing code bases formatted slightly differently, just one of the things you have to get over, IMHO. Like camel notation version underscores versus dashes.

That's a pretty good point. Indentation is indeed just one small aspect of the overall code style - why would you want to have that configurable and nothing else?

Thanks for posting the original s-expr based, tab bashing article!

It has always been my own argument in favour of tabs:

- The original argument against tabs was based on Lisp indentation rules.

- Languages with very complex indentation rules like Lisp should use spaces. There's no exception to this rule.

- Languages from the C family should use Tabs, as Lisp indentation rules don't apply to them.

- Nowadays almost all popular languages can be considered to be part of the C syntax family. Python and Lua are notable exceptions. PHP and Objective C files should use tabs.

Never let get facts in your way.

http://trac.common-lisp.net/mit-cadr/browser/trunk/lisp/zwei...

MIT's Zmacs, the editor of the Lisp Machine indents with tabs.

Good find, thanks.

However, one very old editor using tabs doesn't mean Lisp programmers actually prefer them. It may even be the cause of tabs hate.

If the editor of the Lisp Machine, which was used by people like Steele, Stallman, Pitman had no problems using tabs, it can't be that Lisp has a technical requirement not to use tabs. Steele wrote a book about C. Stallman wrote a Lisp in C and a C compiler...

Basically your arguments are from a strange parallel world.

it's also been rebutted to death.

+1 for the kernel coding style

I can understand (grudgingly) 4 spaces for Python

But for C/C++ 4 spaces are awful. Maybe because C lines end up being longer?

Tabs, they exist. Use them

My editor automatically converts [TAB] to four spaces. Works just fine for me.

And?

Every editor can do it, I'm not complaining about pressing the space bar 4 times.

I'm complaining about the appearance of code indented with 4 spaces.

Well, it shouldn't be a problem if you keep your source files clean and properly use tabs for indentation. Then everyone can set their editor to render tabs at their desired width, whether it's 2, 4, or 8 spaces.

It's ludicrous that these space-wielding heretics (to borrow from the kernel style guide) are keeping everyone from having that.

Every editor, or at least every good editor for programmers, can convert 4 (or whatever) spaces to tabs. If it bothers you that much, you can set up your editor so that it tabifies files when opening them and untabifies when saving. This way you won't even know if the file used spaces or tabs - and that's how it should be.

In short: configure your editor to display to your tastes and save to whatever style guide you use in your organization. Problem solved.

You might be shocked by how many editors can't convert indentation spaces to tabs.

You might also be surprised by how many source files with indentation spaces have off-by-one indentation errors.

> You might also be surprised by how many source files with indentation spaces have off-by-one indentation errors.

I will add that to my list of arguments against using spaces for indentation. It is so true.

Ups. good luck then; that is bound to conflict with other editors; I think the Visual studio editor (or eclipse?) used to have 4 characters for tabs, if everybody is on Visual studio then you are fine. Of course if everybody in the shop has the same editor / editor settings then life is easier.

vim has 8 spaces for tabstop and that's what its docs say:

"Note: Setting 'tabstop' to any other value than 8 can make your file appear wrong in many places (e.g., when printing it)."

Tabs should be abolished, it is a pain to edit source code full of spaces and tabs characters mixed everywhere.

Then the additional issue that everyone maps tabs to a different amount of space characters.

Only spaces can give a proper consistency without relying on external tools.

What external tool can't interpret a \t character correctly?

To me, the problem is consistency. I'm a 4 space man myself, but tabs don't outright offend me, as long as they're everywhere. I'd rather commit edits with tabs than attempt to convert the whole project to spaces, or worse, commit some spaces and some tabs to a single file/project.

For example when everyone has a different meaning how many spaces a tab represents, you end up with multiple amounts of tabs on your files.

This fully breaks the indentation, which is exacerbated when multiple teams working on the same code basis use different editors and tab settings.

So in the end one needs to rely on external tools that go over the source code to normalize the use of tabs.

No, that's what a coding style is for. Either specify tabs or spaces and you enforce it

A tab means 8 spaces. If you want your editor to show something different that's up to you, but it's non standard.

Which only works on small hobby projects, startups and a few companies of the likes of Google, Facebook and friends.

On the real corporation world, it is a whole different thing.

Good luck enforcing coding styles across multi-site projects, with rotating developers and off-shoring subcontractors.

Yes, it is hard. There are ways of putting a trigger in your source code control to enforce it, but it's not always possible.

Still, projects like this have something very thorough and that goes much deeper than just tabs vs spaces: http://www.stroustrup.com/JSF-AV-rules.pdf

A tab does not mean 8 spaces. That's the whole problem, people keep thinking tabs and spaces have an exchange rate.

If you have a source file with only tabs (and you should, then nobody has to run an re-indent script because they can't read it), you should be inserting tabs. If you have a source file with only spaces, you should map the tab key to insert the correct amount of spaces before editing. If you have a source file with both tabs and spaces for indentation, you should re-indent.

For all purposes, yes it means 8 spaces.

Type this in a bash terminal: $ printf '1234567890\n\tx\n'

For the second paragraph: I couldn't agree more. There's even some "geniuses" that indent python with the 1st level being 4 spaces and the second level as a tab. * sigh *. Really.

What about this?

  printf '1234567890\n1\tx\n12\tx\n123\tx\n1234\tx'
  1234567890
  1	x
  12	x
  123	x
  1234	x

Tabs are not fixed width, that's the whole point of their existence.

Yes, this is how it works for alignment, so you don't need spaces to align the x there

This is a non issue when you have nothing to the left of the code (that is, when indenting)

(and the x should be under the 9 btw)

tabs for indentation, spaces for alignment

If there was an automated tool that could apply that I would agree with you.

And if you mix both every language that relies on indentation (Python e.g.) throws you a nice warning or even an error.

The only exception I can think for the 'use tabs' rule in languages without Lisp syntax is precisely Python.

Therefore, to me, your 'every language' reduces to a list of one.

Indentation is also significant in Haskell, for example.

Something I wrote up a long time ago:

https://docs.google.com/document/d/1HMxg6fv_yig_mVvnxsC8CwTf...

Unfortunately I haven't had time to update the code, and it doesn't work with more recent versions of emacs. Now I'm using vim and all-spaces-all-the-time.

What breaks the alignment is editors inserting spaces instead of tabs. A tab is always the same length, but the number of spaces varies between users.

Indentation should be done with tabs.

However, after a character that's not a tab, i.e. any printable character, spaces should be used.

It is the best of both worlds, and can never be misconfigured by changing the number of spaces that a tab represents.

It is also what tab advocates have been saying for years now.

I always felt that using tabs for indentation and spaces after tabs for "prettying" by aligning, say, function parameters nicely seperates the semantics of white space.

Then again, i haven't had the chance to define the coding style guide of anything bigger than a hobby project, so i might be lacking pragmatic experience.

Why is this still a thing that people have to care about? Can IDEs still not automatically convert between company-style and personal-style?

(Sad that tabs solved that problem decades ago (by having a byte that means "+1 indent" instead of having to build some ascii-art that looks like an indent) but people screwed up the implementations so badly :( )

Proper indentation (tabs for indentation, spaces for alignment) is still pretty hard to configure in most editors in my experience. Even in emacs I had to install an external package to get it to behave properly (and it still breaks from time to time).

Failing that I'd rather people just used spaces and no tabs. Using tabs for alignment just means it's going to look fucked up everywhere else. At least spaces are consistent.

There's a lot of fiddly bits.

And my IDE is called "vim".

Sometimes it's called "ed".

Hah... if you think 2 space indents are bad in shell (and C++), you should try writing python with it (yes, google coding style, in a fit of madness, insists that engineers try to keep python blocking straight with 2 space indents. Remember, some of these hapless folks are maintaining large bodies of production python code (as opposed to itty bitty automation scripts).

Google mandates 4 space indentation according to this: http://google-styleguide.googlecode.com/svn/trunk/pyguide.ht...

Oh.. hmmm.. so this has changed since the (first and) last time I tried to get a piece of python code through a review at Google. Looks like better sense has prevailed finally. (There's a version number on that public document but as far as I see, no version history so I could tell when the change happened.)

Wayback Machine shows the document recommending 4 spaces when it was first released in 2009.

Looks like the google's external style guide is saner than the internal one :-) I was talking about the internal style. I can't even begin the fathom the reasoning for the internal style.

I think 4 spaces is for public code and 2 spaces for internal code. FWIW, I got used to 2 spaces quickly enough, and now it doesn't bother me using either 2 or 4, other than sometimes forgetting to change the setting on vim when changing between projects.

Yeah, there are some minor differences between the internal and external style guides. Tab width is one of them (it's 2 spaces internally)

Weird, because the whole Google App Engine source uses 2 space indents.

It's fun how the "tabs vs. spaces" war is relevant only where it doesn't really mean anything.

See, most of the languages (I've seen so far) have a well-defined rule of identation. The thing you get when you do "select all, ident file" in your IDE / editor. At this point it doesn't really matter whether you use spaces, or 2-space tabs, or 4-space tabs, or mix, or whatever - there's only one way non-whitespace characters can be positioned, so it will (in theory) look the same on every editor after you reindent it.

The only place where the choice of tabs vs. spaces actually matters is when you want, for some reason, to break the default rules of identation for your language and position something manually. But in this case, there's no debate; tabs are not suited for precise, manual positioning. Only spaces will be guaranteed to make the code look the same everywhere.

Umm... No...

Yes, the IDE does this, but indent-length and tabs/spaces is mostly ALWAYS definable within the IDE's settings, and is more related to the IDE than the language you are currently editing.

I am extremely annoyed when I try to click at the beginning of a line and I clicked a bit too far left and the cursor gets placed _before_ a space because spaces are being used instead of tabs.

Totally. I love the kernel style over anything else. Even the GNU style for C isn't something I am very fond of.

Still there are some languages where 4 spaces indent is fine. But two is just horrible. Also I like tabs. Convert tabs to spaces in the editor and it works out pretty fine. 2 spaces is just too cluttery.

Gentoo is extremely thought out and over engineered. They seem to do most everything right. . . It's just so much work though.

Note also on the [[ ]] usage... you'll see that [[ ]] won't work for boolean algebra ie. '||' and '&&'

"The majority of people prefer it this way" seems like the perfect justification for a coding standard. Consistency is way more important to me than perfectly matching up with some specific ideal.

The Gentoo documentation is a programming guide and doesn't advise on style. The Google style guide doesn't explain [[ because it is out of scope.

The sheer number of replies to this point is staggering, for what really ought to be a total non-issue in this world.

Someone needs to make some kind of GitHub integration that lets you download code using whatever esoteric formatting you prefer, then transform back to some given standard on commit. Then everyone can finally just agree to disagree and get on with life.

That reference is the best I've seen. Thanks for that.

Reply on news.ycombinator.com