Hacker News Reader

> also serves as a nice illustration of the fact that if tabs are allowed in source code, people will mix them with spaces

This seems disingenuous, I could just as well point to a piece of code and say "if spaces are allowed in source code, people will mix them with tabs". People should get over themselves and accept some people prefer a single character to specify tabbed-space and other people want the exact number of spaces. I find space characters cumbersome to work with, so I use tabs myself.

In addition, most editors these days should be able to fix this as you go so you can use whatever your preference is and comply with the projects standards.

I'm not sure how the parser and lexer/etc. line count matters for the VM line count. shrug

Definitely something I'll be looking at for my embedded work; it may fill a gap in my toolchain. And boo-hiss tabs.

Parser and lexer matter for the multipass compiler.

Which isn't the VM, right?

No, it's the compiler. Are you still overlooking the phrase "the multipass compiler code is about 3K lines" in my original post above?

> And boo-hiss tabs.

At the risk of starting a flame-war: boo-hiss not using a formatter.

Orthogonal. Once you have tabs, any viewing of that file will rely on the tab size set by whatever viewer you're using: mixing tabs and spaces basically never works. At least if it's just tabs everything will be seen wrong consistently.

The only reliable mechanism is spaces-only.

:p

But if you're using a formatter then it doesn't matter whether you use tabs, spaces, minimal whitespace, or any mix thereof because that's what the formatter is for.

Also if you're using a formatter then you can do the correct thing and use tabs for indentation and spaces for alignment, because the formatter will ensure that the output is consistent.

The output is consistent if your tab settings are always the same when you look at your code, and you use the same tab size across all languages.

I view code in multiple ways, have different indentations for different languages (not many different now), and have clients that enforce difference indentation settings. It just doesn't work.

> The output is consistent if your tab settings are always the same when you look at your code, and you use the same tab size across all languages.

I don't really understand what you're getting at here to be honest, surely if you change your tab settings it's because you want the code to look different?

> I view code in multiple ways, have different indentations for different languages (not many different now),

This is exactly what tabs are great for! You can set the tab width based on language without having to force that choice on anyone else.

> clients that enforce difference indentation settings

Again, formatter.

I'm not sure if you're being deliberately obtuse, or just never look at files in only one way. I don't have that luxury.

Say I have a project that has Java and Rhino (JavaScript) files. My IDE/editor is configured for Java with TAB==4, JavaScript TAB==2. Everything looks great in my editor, because it knows things.

Now I'm using `less` or `cat` in my shell. Or ssh-ing to a remote box because of an emergency production issue. Or whatever. Now when I look at the file things no longer line up as originally intended, because when I view them outside of the (relatively) smarter IDE the TAB characters are at the mercy of whatever I am using to view the file.

You cannot simply rely on local tab width settings if files use a mix of tabs and spaces for indentation and alignment: if you change the tab width then alignment breaks. If you never align anything, great, tabs work great for indentation (except for when you can't trivially change it, then they suck). But indentation isn't the only thing tabs are used for.

There's the rub: TAB characters will always be at the mercy of how I'm viewing the file, which I do not always have control over, and certainly not (trivially) based on the type of the file.

> You cannot simply rely on local tab width settings if files use a mix of tabs and spaces for indentation and alignment: if you change the tab width then alignment breaks.

Ah I think you've misunderstood what I meant by tabs for indentation and space for alignment (something which you will be controlling with a formatter because that's the entire premise of my original comment). I'm not sure how to make it more clear, so I'll give you an example.

  class SomeClass {
  [tab]functions some_method(with, arguments) {
  [tab][tab]return a_function_call(with,
  [tab][tab]                       lots,
  [tab][tab]                       and,
  [tab][tab]                       lots,
  [tab][tab]                       of,
  [tab][tab]                       arguments);
  [tab]}
  }

Is that clearer?

Yup! Now view that across multiple languages, viewers, and tab sizes.

> the fact that if tabs are allowed in source code, people will mix them with spaces, resulting in code that looks bad unless you have the exact same tab width preferences as the author.

Every bit of go code shows you are wrong. If a codebase uses tabs for indentation (which is the only place they should ever be allowed) then it's a mistake to use spaces for indentation. My first ever contribution to a free software project (when I was about 15) used the wrong whitespace for indentation. They made me fix the patch and that is how I learnt about whitespace. The example you've shown is just an example of bad code standards, not tabs being bad.

The problem with the code in question is a problem of alignment, not indentation.

Edit: Ah, no, there are some indentation problems too. But it's the alignment that I first noticed because it's so jarring.

Wow, yeah, that's why should never change tab width to anything other than 8 unless you're very sure that you've got things set up exactly right tooling-wise.

If you open it in an editor, you'll see no indentation problems: https://monosnap.com/direct/cSBUU3ik31upjfdxpc8p9RJjLyVtda

This is a result of using 'elastic tabs' which GitHub is not able to display correctly (and also the reason people will use spaces for alignment in a tab-indented project).

If you open it in an editor and have the same tab width configured as the author, you'll see no indentation and alignment problems. If you set a different tab width (the purported advantage of tabs), the code will be messed up (the actual disadvantage of tabs).

Not sure why you blame this on GitHub. Emacs with a tab width of 2 or vim with a tab width of 8 will also show this code with broken formatting.

Yep. It's not a github problem, it is a problem with the code mixing tabs and spaces for indentation.

It never ceases to amaze me just how many programmers don't understand tabs. I guess it's because they look like spaces Or because every programmer at some point got bitten by the issue but instead of learning how to use tabs correctly learnt that tabs are evil.

The tabs vs spaces war is all just a massive misunderstanding due to some people (the spaces people) not understanding tabs (and not understanding that nobody is advocating using tabs for alignment purposes).

> not understanding that nobody is advocating using tabs for alignment purposes

It's not about advocating, it's about actual use as in the example above. Tab fans get confused about what they are doing and put hard tabs where there shouldn't be any.

If tab users were actually perfectly consistent about using only tabs only for indentation but not alignment, things would be fine. In practice most of them don't understand the issues and even those that do understand them apparently fail to be consistent in practice. Which is not surprising, since tabs are just as invisible as spaces in most environments.

I've said it before, I'll say it again: I've worked on several projects that were halfway through a painful tabs-to-spaces transition period, and they all said "no tabs in new code, never again a project where we allow tabs". I've never had the opposite experience. In practice, as used by actual humans that need to work together, tabs don't work well.

Yeah, I guess that is also my experience and it correlates with what I do. I think that tabs for indentation and spaces for alignment is correct, but in practice I use spaces and have done for most of my career (apart from go).

Tabs polute an otherwise perfectly simple concept, fixed width fonts. If they had't existed out of the gate, no one would have ever considered asking for it, especially if the reason was "I want to be able to pick my own indentation level". They'd be laughed out of the industry. You want the whole world to worry about your prefered indentation level every single time they start a new line? Thats never going happen. Take the indentaion level your given and burden yourself with the task of writting a feature for your editor that lets you pick what you like instead. Oh, and have fun fighting with it every time you open a file you didn't write.

This is easily solved with something like .editorconfig.

I personally use four spaces. What I was trying to point out is that this is not necessarily "bad code standards" from the author. As long as everyone in the project is onboard, and tooling support means the code is perfectly readable, I really don't care if you would use seven poop emojis for indentation.

    uint32_t<3 tabs>pc;
    double<4 tabs>time;

That's not how elastic tabstops work. With elastic tabs you only put one tab between each and every field.

(Besides, not all editors support elastic tabstops, not even with plugins.)

Perl best practices understandably has a problem with this type of tab usage. It only allows for tabs after a newline and before any actual code but not inside code (for alignment).

All the world is not golang.

Go is actually one of the few exceptions in the world due to having had "go fix" baked into the compiler/ecosystem from the start. That makes a huge difference.

It's also quite a simple language and is pretty easy to auto-format reasonably. Few other languages are that easy to auto-format or have that kind of culture where auto-formatting is accepted as a matter of course.

Nit: you probably mean "go fmt".

"go fix" is a different tool. (Though "go fix" does also run the formatter.)

Rust is working on this:

    $ rustup component add rustfmt-preview
    $ cargo fmt

(And rustfix for the “go fix” equivalent.)

Go is actually extremely hard to format automatically:

http://journal.stuffwithstuff.com/2015/09/08/the-hardest-pro...

That article is about Dart, not Go.

Furthermore, the difficulties it mentions are pretty much universal across languages.