Hacker News Reader

Comment by simias | Hacker News Reader

I don't mind opinionated coding style (my Rust integration scripts all enforce that stock "rust clippy" doesn't return any error) and I do think that using tabs for indentation simply doesn't work in practice regardless of how great they are in theory because hardly anybody uses them correctly (including the vast majority of code editors by default). It might be strange to back it straight into the compiler but I don't mind it.

That being said it does make it even weirder to allow braceless ifs IMO, but that's bikeshedding.

View on HN

> including the vast majority of code editors by default

Which ones exactly? Not really a problem I've encountered often except when someone tries to mix both spaces and tabs, and in general editors are built with the existence of this very common character in mind. People tend to hit the tab key to indent anyway, and one tab char meaning one level of indent is perfectly intuitive and allows users to individually configure how large they want their indents to be.

the problem i encounter is when you try to break a long line into multiple lines. if you want to use tabs and align the continuation, you should be mixing spaces and tabs.

for example ('-' is tab, '.' is space):

    --function_with_lots_of_arguments(arg1, arg2, arg3,
    --................................arg4, arg5, arg6);

it can be done, but a lot of editors get it wrong and it requires paying attention to the whitespace.

of course, another style would be to just indent the continuation twice, without aligning it. (i personally prefer to align continuations.)

Some food for thought: https://youtu.be/ZsHMHukIlJY?t=633

For example, this is the best way to define functions with argument lists long enough not to fit on a single line:

  fn doThing(
      argument1,
      argument2,
      argument3,
  ) {
      <code>
  }

Visually clear, doesn't have any spaces/tabs issues, produces minimal diffs when adding/removing/renaming arguments.

Very interesting talk! Thanks for the reference.

More food for thought:

The style in your example is more consistent with the way nearly every programmer formats code that has more than one statement. For example:

  if( shouldDoThings ) {
      doOneThing();
      doAnotherThing();
      doLastThing();
  }

Why do we want to format statements that way, but function calls and expressions a different way? No one would write this:

  if (shouldDoThings) {doOneThing();
                       doAnotherThing();
                       doLastThing();}

I have a theory about that but will have to save it for another day.

Somewhat related, the Rust coding style guidelines used to follow a heavily column-aligned style, but changed to indentation-only a year or two ago. I posted an example from the Servo source code with the old and new formats here:

https://news.ycombinator.com/item?id=18962177

Many editors (including the venerable Vim and Emacs) indent and align with tabs by default, which means that if you want your code to look right you standardize tab width which in turn removes one of the only (meager) advantages tabs have over spaces: configuring the indentation width to match your personal taste.

>Not really a problem I've encountered often except when someone tries to mix both spaces and tabs

Mixing spaces and tab for indentation and alignment is how it should be done if you want things to remain aligned when you change the tab width.

>Mixing spaces and tab for indentation and alignment is how it should be done if you want things to remain aligned when you change the tab width.

How it should be done is to never write code that needs alignment if you're using tabs for indentation.

So then it's the editor that's at fault. Most editors let you do a "run formatter on save", and zig has(had? at least it did last I played with it) a formatter that can do correct "indent with tabs and align with spaces" with only a minor tweak

I'm not aware of any editor or auto-formatter that handle the case of https://news.ycombinator.com/item?id=21969323 correctly.

Visual studio does it for C#, at the very least. Other formatters choose other options, and it's a matter of preference in any case (I personally think it's a code smell to have that many arguments or that long of names, and I also don't limit myself to 80 columns, cause I've got a widescreen monitor)

Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments("), add that many spaces after your indentation tabs on the next line, continue arguments. The fact that editors/auto-formatters don't do that speaks far more to their lack of desire for that code style then it does to the difficulty of doing it.

The simple fact remains that using tabs provides many accessibility benefits that spaces are just unable to provide, like being able to drop tab size when you boost font size (legibility for poor vision) so your code doesn't indent off the side of the screen, or far better support for indentation for proportional fonts (another thing that people swear by for increasing legibility).

Just to be clear, I prefer tabs over spaces myself, so I'm not arguing against tabs. What I'm arguing against is mixing tabs with spaces, with the expectation that every contributor to the codebase uses sufficiently smart editors to not break the formatting.

With that out of the way...

>Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments(")

That breaks for `foo(bar(a,\nb,\nc))`

And if you fix it to be "len till the last unmatched (" then it breaks for `foo(bar(a,\nb),\nc)` because the two lines have to indent to different levels.

Just saying it's not as trivial as it seems.

>The fact that editors/auto-formatters don't do that speaks far more to their lack of desire for that code style then it does to the difficulty of doing it.

And is a reason to not use such a style in the first place, as I said.

> Just to be clear, I prefer tabs over spaces myself, so I'm not arguing against tabs. What I'm arguing against is mixing tabs with spaces, with the expectation that every contributor to the codebase uses sufficiently smart editors to not break the formatting.

That's still just an argument for "everyone use a specific formatter with these settings". Go's formatting is simple, built into the main implementation, and has no knobs, as a result, everyone uses it, and all code is formatted with tabs and spaces. It can work, esp. if a language adopts it early (like Zig could have).

> I do think that using tabs for indentation simply doesn't work in practice

It has worked just fine for decades for projects with millions of lines of code.

It might not work for babby's first patch and how do I configure an IDE??

Depends of your definition of "fine". The linux kernel works fine indenting with tabs but it mandates 8-space tabs and a lot of code ends up looking borderline unreadable if you use anything else, meaning that the only thing they get by using tabs is slightly smaller file sizes. Besides if you want to enforce the 80column limit you have to standardize a tab width anyway.

It's simply not worth it IMO. The pros are simply too small and inconsequential to justify not using spaces on new projects. Although now that automatic code formaters are becoming ubiquitous it really doesn't matter what you use in your editor I suppose.

Reply on news.ycombinator.com