Hacker News Reader

Comment by nottorp | Hacker News Reader

Pretty simple: you use spaces because you're aware that there is more than one IDE/editor in this world and who knows what your code will get opened with tomorrow.

This means you consider consequences beyond "but it works on my machine" so you're a better programmer. Ergo, higher salary.

View on HN

Almost everyone I know who uses spaces or tabs does so because that's either the default on their IDE, or for their language. So this holier-than-thou argument holds less water than the sun.

On the other hand, I find 2-space-indented code unreadable; in fact, 4-space wide indentation is the only size I find to be readable. I know plenty of people for whom that isn't the case. Using tabs lets the reader set the indentation level.

¯\_(ツ)_/¯

Edit: All the anti-tab arguments I'm reading below boil down to alignment. Don't align folks; there's good reasons not to align regardless of your indent style.

Actually they all boil down to 'someone else, or another IDE that you haven't configured just right, will mess your tabs and make the code hard to read' :)

They're fine for solo projects i guess, if you only ever use one editor.

Edit: Also, in the long run the best thing you can do to your code is to make it easily readable. You will forget what you did. Not to mention your colleagues that have never seen it. So time spent aligning parameters to make code more readable is well spent, if you ask me.

> So time spent aligning parameters to make code more readable is well spent, if you ask me.

How is this[1] more readable than this[2]?

[1] https://github.com/HearthSim/python-hslog/blob/5a6ad9a29a7d4...

[2] https://gist.github.com/jleclanche/ef40058731061e26d218e2a4c...

Let the lines get long enough and the latter is actually quite a bit harder to read; try to follow the variable all the way to its value and you might actually jump and be one line off.

I deeply care about readability and code style, that's why I'm replying here :) And in all the codebases I have read and written, alignment has consistently been harmful to readability and maintenance.

When I hear "aligning parameters", I think more of the difference between this:

  someFunction(firstParam, secondParam,
    thirdParam, fourthParam);

And this:

  someFunction(firstParam, secondParam,
               thirdParam, fourthParam);

I've always found the second much easier to read, especially when there are multiple levels of nested expressions, and it's a style that has been encouraged on every project I've worked on.

I agree that aligning '=' is actively harmful in the example you give, and that it's harmful in most situations where it's used. I've encountered very rare instances where it's helpful, though. Sometimes you have a sequence of values defined by expressions that follow a pattern:

  enum someEnum {
    FIRST = BASE + MASK & (1 << 0),
    SECOND_VALUE = BASE + MASK & (1 << 1),
    TH = BASE + MASK & (1 << 2)
  }

Aligning the expressions can make it more clear what the pattern is and how it differs from value to value:

  enum someEnum {
    FIRST        = BASE + MASK & (1 << 0),
    SECOND_VALUE = BASE + MASK & (1 << 1),
    TH           = BASE + MASK & (1 << 2)
  }

Often there are other ways to handle the issue, such as hiding the expression behind a macro or a function call; when that's more readable, that's the way to go. But in cases where writing the expression explicitly ends up being more readable, I find alignment to generally be a win in this case.

I think you've just figured out why people who use spaces get paid more: they spend more time aligning the code nicely :D

Any coding standard that relies on humans to do something right is going to fail. Tabs might work if there was a way to automatically enforce no alignment and no use of spaces. But I've never seen any organization actually do that.

> But I've never seen any organization actually do that.

You haven't looked very far! Most open source projects these days enforce code style through some forms of tooling.

But saying that "Any coding standard that relies on humans to do something right is going to fail" is basically giving up and saying "do whatever". I mean, why even ask people to indent consistently if it's doomed to fail? It's a mixed indent party for everybody!

> You haven't looked very far! Most open source projects these days enforce code style through some forms of tooling.

Sure, but I've never seen a tool that was able to enforce that no-one was doing alignment.

> But saying that "Any coding standard that relies on humans to do something right is going to fail" is basically giving up and saying "do whatever".

Coding standards that you can implement in your enforcement tool are fine. But any rule you can't automate is not worth bothering with, IMO.

> I mean, why even ask people to indent consistently if it's doomed to fail? It's a mixed indent party for everybody!

Use a language that enforces indentation, or use a tool to autoindent. Trying to get people to indent consistently by hand is a waste of time.

clang-format, Uncrustify, YAPF, and RuboCop all have options to control alignment.

With the spread of autoformatters which automatically format or reformat your code, I don't even know or care what kind of indentation I use anymore. In all the languages I use, it's out of my hands.

Examples of autoformatters:

YAPF for Python

Gofmt for Go

Rustfmt for Rust

In fact, tabs are better for compatibility: other people might like other indentation sizes. If you keep your stuff consistently with tabs, and use spaces for alignment instead of having your IDE auto-replace tabs there as well, your code will look great with whatever tab size someone chooses. And extra pro: in dumb editors, you automatically get the right thing.

unless you have anything aligned in columns then all bets are off (something which many code formatters can do automatically for you e.g. lists of bindings)

Tabs for indentation; spaces for alignment; I don't know why you'd want to insert tabs in the middle of a line.

Also, most people who do have several years of experience under their belt will tell you: don't align. Mid-line alignment is a waste of a maintainer's time to have to update alignment blocks every time you add/remove variables... and statement-alignment is unreadable[1].

[1] https://github.com/pennersr/django-allauth/blob/a44134688f5b...

> Tabs for indentation; spaces for alignment

On a large code base with multiple committers, I've never seen this rule followed consistently. In fact, I think this shows a poor engineering decision: "Let's make a rule where everything looks OK 95% of the time, except when you change tab widths (which is, presumably, why we made the rule in the first place.)"

Well everything looks OK 100% of the time if everyone followed the rule. Sadly, human history tells us that's an invalid assumption to make.

Forcing people to remember relatively minor things is a poor use of headspace. Enforce a code formatter/linter, make the test suite success dependent on it, and never argue again.

I often run into trouble with IDEs that think they are smart, but aren't. "I see you have a space following a tab, so I will replace all your spaces with a tab, whenever you save the file"

I don't see how that code is unreadable, but for me it isn't representative of how I would align that block anyway.

I do find properly aligned code easier to read in general, I'm not willing to give that up.

The crux of the issue is poor tooling. Aligning correctly is a pain because most editors suck terribly at it. For instance neither emacs nor vim align correctly when using tabs by default (they use as many tabs as they can and then pad using spaces, instead of indenting only with tabs and aligning only with spaces). If they did it would be painless to indent and re-indent.

When some of the most venerable code editors out there can't even seem to get it right I think there's no point in fighting it. Learn to stop worrying and love the space, I know I did. Or alternatively use a language like go which provides a standard tool to indent everything, make it mandatory pre-commit and never look back.

Yeah; the correct answer to a good codestyle is good tooling; high quality automated tooling. Things like gofmt and prettier are excellent. yapf and clang-format are also pretty good, but need a lot of set up.

But I never found a single editor that handles spaces correctly. I currently use vscode with vim bindings and whenever I deal with a space-indented codebase I want to tear my hair out: I inconsistently have to hit backspace sometimes once, sometimes multiple times to get rid of an indent level in insert mode. And don't get me started with yaml, a really painful experience to edit it.

Can't vscode automatically remove an entire indentation level with a single backspace? Many editors can do that, maybe with a non-default setting, but regardless.

> Tabs for indentation; spaces for alignment;

If you try this, it fails for people who use a different tab size than you, which is the whole supposed point of using tabs.

But yes, the correct answer is don't align. Utter waste of time.

This entire thread is why I love gofmt so much. I haven't thought about this useless bullshit for years.

Myself, working on an old open source project, I just don't care. Match the nearby style best you can, use your own style on new code, who cares, get on with your work.

> If you try this, it fails

If it fails, then you have not understood and you are not using your tools correctly. If your alignment depends on tab width, then you are not using tabs for indentation and spaces for alignment, you are using tabs for indentation and alignment and spaces for alignment, which of course breaks when you change your tab width.

Ah, I see what you mean. I've never seen an editor work this way, normally they just swap spaces with tabs, leaving however many spaces can't be swapped. Which is probably why I've never seen tabbed code in the real world that doesn't look like utter garbage.

This was definitely a problem back in the day, but I think most popular editors do the right thing now. And like you say, alignment is usually a waste of time anyways.

The alignment in that link is laughable. Please use newlines and an extra indentation level.

I believe older versions of Xcode did that by default with objc (maybe still; didn't check lately) if you press enter in the middle of a function argument list. Really annoying.

Tabs are only better for compatibility if you know that no one who touches the code will ever use spaces.

But the same is true for spaces...

What kind of a dick opens up a tabbed project and starts inserting spaces? Even if you have a preference the other way you play nice with others and stick with the project conventions.

The other thing you need to do is stop people from checking in code that doesn't follow project conventions.

Oh, I've got some good examples :D

https://github.com/ioquatix/rack-freeze/issues/2 https://github.com/ioquatix/latinum/pull/1

From the linked issue:

>deliberately have my editor set up to change tab width based on editor width (responsive indentation width)

What editor are you using that has this setting?

There are a couple of ways I have this set up.

Firstly, I've explored using responsive tab width in https://github.com/ioquatix/jquery-syntax which is nice when presenting code on a mobile phone.

Secondly, I've got hard coded tab width on my desktop with a huge screen vs my laptop with a smaller screen, and this works for all editors, including my primary editors Atom and vim.

Finally, I've played around with using responsive CSS within Atom, but due to recent changes in the text rendering my current CSS doesn't appear to be working.

https://sourceforge.net/p/texstudio/hg/ci/69381fad4634edc4fb...

We enforce that: spaces break linting.

Trivially easy to set up your editor correctly once (if you even need to) and now everyone gets their preferred intenting size

I have never seen this work correctly in practice, where a code base with tabs looks "OK" when opened on an editor with a different tab width. E.g. some coding styles will have subsequent lines line up (like multiline method params), and everything looks horrible with a different tab width.

If anyone can post a sizable production code base that uses tabs that DOESN'T look like shit with a different tab width, I'm certainly open to being proven wrong.

> sizeable production code base

Here and there's the problem. Too many people with editors that go round replacing N spaces with tabs everywhere to have sane alignment in a code base with >1 developer...

FreeBSD, Linux ... every UNIX kernel codebase ?

This feels like a partial proxy question for Unix versus non-Unix development. Unix developers are, in my experience, consistently more interested in configuring their IDEs, which underlies many of the arguments for tabs over spaces.

Linux looks like shit with any tab width besides 8. Simple example: https://github.com/torvalds/linux/blob/master/kernel/livepat...

Notice there are a couple examples in that code where multiline method calls are meant to line up, and if tabs are not set to 8 they don't line up.

That's the problem with a space-tab mix.

I do it myself but it requires a bit of maintenance and I wouldn't trust teammates with it. There will always be some guys who don't understand the idea and mess everything up.

In a team environment, now, I wouldn't chose anything but 4 spaces. Speaking from experience.

- with anything but 2, 4 or 8 spaces, some guys with incorrectly set up editors will mess everything up.

- tabs don't work well for alignment, and as long as you allow the tab character, someone will make a mess.

- 2 spaces is not enough to properly distinguish between blocks.

- 8 spaces can look very nice if your code is very clean. It won't be the case of your project.

That's the reason I use tabs for indentation? 4 spaces will render as 4 spaces, 2 as 2.

1 tab will render to whatever the next programmer prefers, it's only courteous.

It's courteous except to those that don't like tabs, so you really can't win.

Many languages have a coding style preference. Go is super opinionated, Python in the middle, with C being as conflicted as it gets. Whatever you use, follow the style the language or team is a proponent of.

If you don't like tabs, converting them to spaces is trivial. You could even add git hooks to do it automatically.

If it's your own personal code-base, go nuts. If you're working on a team don't be the one who does this and wrecks every file you touch.

Picking one or the other will be slightly discourteous to the other side, in this case this is an advantage only tabs hold.

^^^ Exactly. Using tabs is a decent (albeit not perfect) indicator that you've never worked under source control on a large dev team with diverse working habits.

I think there's probably some truth to considering existing norms and thinking ahead, but find it unlikely to be the main confounder. How do tabs fail to work in other editors/IDEs?

Tabs fail when my IDE is set to convert tabs to spaces and yours isn't.

Additionnaly diff/merge tool tend to be inconsistent. So it looks good on your editor, but when I am doing your code review, alignement is totally broken. In theory, it should be easy enough to ask people to have consistent settings across all tools, but it is a bit like herding cats. Sadly most people do not even realize it could look differently without their settings. (I could ignore whitespaces when doing reviews but this is an open invitation to break everything)

Seriously? When you start on a project you configure your IDE to match the project's conventions. If you are in a mentoring role you instruct your jr developers to do the same, first thing, before writing any code. This has never been an issue at any place I ever worked. If a PM can't get their developers to do something as simple as that then you have larger organization problems than code formatted weirdly. As well as totally incompetent developers.

On a very large codebase, developed over decades, not months or years, by thousands of individual teams, using multiple versions of multiple IDE's, some of which didn't exist when the project started, across different languages, also some of which didn't exist when the project started, this is not so simple.

Unless the project's settings are to use spaces.

I've worked on projects that have been developed over decades and there has never been an issue. We have conventions, developers are expected to follow conventions, and if they don't they are instructed go back and fix their code.

Spaces when tabs are used. Your point?

In that case your IDE fails.

Respect .editorconfig files

They might be configured differently, and you usually can't align stuff properly using just tabs, you have to use a space or three somewhere. Also, you never know if it's spaces, tabs or a combination of them in existing code - which you may have not written yourself.

So in the long run, the indentation WILL get fucked up and you WILL miss something when fixing a bug in code that you or someone else wrote 6 months ago. And your 10 minute bug fix will take 3 hours. Multiply both values by a constant factor as necessary.

It's simply not worth the trouble.

>you usually can't align stuff properly using just tabs

Huh? Things indented to 1 tab will align with everything else on 1 tab. Things aligned to 2 will align with everything else at 2 tabs.

>you have to use a space or three somewhere

Why? Tabs will indent with other tabs.

>you never know if it's spaces, tabs or a combination of them in existing code

Well they should never be combined for indentation. Unless you mean using tabs for indentation and spaces for alignment, but this wouldn't create any issues. Using tabs for spacing is objectively poor form.

I open space- and tab-indented files in my IDE, they are all converted to tabs. It is always consistent.

Oh god. I also prefer tabs, but if a file has a choice of tabs or spaces, never change the whole thing to what you prefer. Always keep it as is.

Good point, in my case that's just how I work on it, git magic converts it to whatever matches the repo style before it's committed.

>you never know if it's spaces, tabs or a combination of them in existing code - which you may have not written yourself.

Um... I always know because I always set my IDEs to show those characters. You don't?

I don't think the answers here really make a clear case that tabs are the cause of the IDE/editor problems. People intentionally introducing incompatibilities (mixing tabs & spaces, setting their editor to convert) seem to tbe cause. And that would apply regardless of the initial choice.

That's exactly my experience, too. Developers who use default settings and tools are less interested in computers. Knowing the details of a system makes a developer infinitely more valuable.

Reply on news.ycombinator.com