Indent with spaces: When the ASCII art needs to line up.

Indent with tabs: To save time time adding/deleting characters or squinting at exact boundaries.

Better than both: Files are saved with spaces, but the code-editor is smart-enough to act as if the multiple spaces are a tab during editing or when setting a custom tab-width.

I have yet to see an editor that will truly work with spaces that way. Sure, the tab key will insert spaces, and the backspace will remove multiple spaces if you’re at a whitespace boundary, but I still have a much smaller click target when selecting the beginning of code (i.e. 1/4 the amount of space to click to get the cursor directly before the first non whitespace character, or when dragging to select the code on a line).

I always find that I’m clicking a bit too early in the “tab,” not selecting where I want, and then backspace is treating it like normal spaces again so things aren’t aligned.

I’d also love if it could render “tabs” of spaces at different widths, so that if one person wants to look at 2-space code, and another finds it more readable as 8-space, they have that option.

And anyway, all of this is only to help when a codebase is spaces when you want tabs, because I don’t see much benefit to saving out spaces if you’re going to go to all of this effort to emulate tab behavior.

> but I still have a much smaller click target when selecting the beginning of code

I would be shocked if your editor didn't have a much easier option for you. For example, in Jetbrains tools I can just:

    1. Double click on the first word to select it.
    2. Shift click anywhere to the right of the final newline.

Or also:

    1. Click anywhere at all on the line.
    2. [Home] button to go to start of content
    3. [Shift]+[End] to select to end of content.

That second one in particular resists any problems with shaky hands and squinty eyes.

Stop clicking, mate.

While you can definitely get a speed up from going keyboard only and mastering hotkeys, you are way faster at selecting some random block of code with the pointer and retargeting to somewhere else to paste etc until you have them solid.

For everything I write, that marginal speed improvement isn’t even close to worth the learning cost of 100% ditching the mouse. I’m bottlenecked on deciding what I want to express, almost never how quickly I can enter it into the computer. I just want it to not be a “clunky” experience, i.e. once I decide to select a block of code to move it somewhere, I want that to be painless.

For that, tabs give a nice large margin for error on the click targets, which means I can move faster.

Why do I use Emacs for almost everything? I broke my shoulder that supports my dominant hand. Seriously.

Thank God I did not break my pinky.

I knew another student who worked the university computer lab help desk. His comment about a ski injury was "at least it wasn't my space bar thumb."

Indeed, sounds more like a skill issue to me ...

Edit: sorry someone else already said it in another part of the thread

The reason to use spaces is it keeps any alignment of multiline statements the same. You're not supposed to be able to adjust it because adjusting it means you can't do alignment, unless you use mixed tabs and spaces.

In my opinion, you can generally write very nice looking code even if the indentation of the multiline statement isn’t exactly matching the brace or whatever.

But as you say, you can still use spaces for alignment. I find it to be kinda meh because if the alignment has to change (like adding a longer variable name) you end up touching lines you didn’t otherwise have to in your diff.

Also, if we’re talking about editors doing nice things with tabs, I think you could make an editor look at the tab in and align things exactly how you want in rendering for a multiline statement.

Another factor is the reduction of codebase size, using tabs, which is significant for something like the linux kernel.

I am trying to imagine in what context that is relevant. Trying to compile the kernel on an embedded system?

> which is significant

[Citation Needed, preferably with Actual Math]

I found one attempt to quantify the issue [0] which found differences which I don't think are very compelling, especially when you consider how insanely cheap disk space is compared to even a tiny time-savings in developer workflow.

Here, some napkin math just to put the orders-of-magnitude in perspective:

    1. Assume the entire kernel repo is 1.5GB.
    2. Assume your format shrinks it to 1.0GB.
    3. Assume a $50 SSD with 1024 GB capacity.
    4. ((1.5-1.0) / 1024) * $50 ≈ $0.025
    5. Assume an *underpaid* developer at $20/hr. 
    6. $0.025/$20 * (60*60) = 4.5 seconds

So the disk-space benefits of reformatting to get the kernel-repo down by a (huge) -33% is wiped out if the (underpaid) developer ever spends more than +5 seconds dealing with the formatting.

[0] https://www.reddit.com/r/C_Programming/comments/auv5mg/file_...

Because the prevailing convention in many languages is to use spaces. In a vacuum, I slightly prefer tabs to spaces for indentation. But I think being consistent with most other code in a language or project is more important than my personal preference.

Because spaces are guaranteed to layout the text to a predictable format, whereas tabs are not since the size can be adjusted and tab-stops don't necessarily line up with obvious word boundaries on the lines above.

The correct way to use tabs is to indent with tabs and align with spaces, that way everyone can adjust the tab size to their liking without breaking alignment.

Then you've got mixed tabs and spaces, which seems like it's going to inevitably lead to confusion when someone who isn't aware of the convention starts to make changes. Two different invisible characters in a single file is a recipe for madness.

By your definition, all Go code in the world is madness?

Newbies editing code is a problem best solved with automatic formatting.

This was once my understanding, and the accessibility argument still speaks to me, but I wish Elastic Tab-stops saw more discussion and support.

https://nick-gravgaard.com/elastic-tabstops/

I'll try to do my part.

I've been writing (and reading) a lot of Lisp lately, and have seen some projects adopt indentation idioms which offset blocks from the regular tab-stop intervals. A standard tab-stop might be +4, but then arguments might be lined up with each-other at +6 (+1.5 stops):

    (list 'a
          'b
          'c)

Any of those arguments could be forms, which might return to the standard tap-stop of +4 but off by 2 (let's call that `+4(+2)`):

    (list 'a
          (with-foo quz
              (bar quz))
          'c)

Lists written with the `quote` syntax might do the same thing, but produce an offset of only 1:

    '(a
      (b
       (c)))

The end result is that changing a code's indentation level (like when raising an anonymous function into a top-level definition) means adjusting the spaces (which were supposed to only be for alignment) if any preceding forms had introduced an offset. The alignment doesn't change, but it's relation to regular tab-stops does. Sometimes, this is an adjustment of zero, but you still need to think about it. In an all-spaces environment you could use vim's visual mode to select the block as a rectangle and paste it into the top level, but with "indent/align" semantics this same situation regularly requires maintenance (by inserting or removing spaces, in addition to manipulating indentation via tabs) to preserve both proper alignment and the integrity of the semantic distinction[1].

I think that elastic tab-stops fix this by correctly modeling indentation is it should be conceptualized, platonically divorced from the characters encoding it. I think that spaces are better than tabs when white-space isn't significant (and personal style might disregard tab-stops), but recognize that tabs are more accessible and worth using when tab-stops are enforced as a byproduct of significant white-space. I repeat that elastic tab-stops are awesome.

1: Someone correct me if vim can actually just do that with tabs just fine, i dont really know, it late~

That doesn't work when alignment depends on the tab size like aligning an indented line below an unindented line like long assignments

    Type myvar = something_very_long +
                 that_needs_alignment;

The only way to guarantee such complex alignment is using spaces. It renders everywhere exactly the same. So reviewing stuff on web-based environments gets easier.

You can do it: by putting tabs on the second line to the start of the first line, then using spaces to match "Type myvar = ".

It's just that sooner or later someone will get it wrong.

“correct way”? This is just your opinion. Everyone has one. Want to read mine? “A text editor should never replace what I type”. Want another opinion? “An editor should always distinctively display white-space characters”.

If someone finds it more readable to have their tabs smaller to fit on a small screen, or larger to fit on a large screen, why deprive them of that?

It’s perfectly fine to still have a canonical width if you want to use it for other reasons, like Linux with their “tab is 8 spaces when deciding whether a line is too long” thing.

This is a non-issue. Or better: not the issue of the person who writes the code.

Simply don't adjust the size. Tabs are 4 spaces wide, I have just declared it.

This is no worse than using 4 spaces to indent. Using 2 or 8 or 3 spaces for a tab is a skill issue.

Ironically enough, the kernel style guide declares tabs to be 8 spaces and anything else as heretical.

Honestly, my reason for liking spaces is "I know what every invisible character in my code is". Since I obviously cannot stop using spaces altogether, I use them everywhere.

Also at work we all use 4 spaces for indentation. Nobody wants a smaller number. We have huge screens, we're not in the 80s anymore

> We have huge screens, we're not in the 80s anymore

I would like to fit more text on my modern screens, and 4-space indentation and 120+ char lines limit how many files I can view side-by-side while maintaining legibility.

I still try to keep my lines around 80 chars long in 2024 for this reason.

100x32 it's a sane size, but I always set 72/80 chars as a limit on messages such as Usenet/email because not everyone uses my setup.

> We have huge screens, we're not in the 80s anymore

Huge screens are useful to show more content e.g. multiple buffers, ancillary information (like docs).

I’m not interested in wasting that additional work space in emptiness because you can’t keep to reasonable line lengths.

I use 4 spaces and short lines because it naturally limits how far I can drift rightwards before I need to refactor or rethink what I’m doing.

Thought I’ll readily confess that rust can be mildly annoying there: lots of things require additional blocks, and the affordances of function scope around split borrows can make extracting utility functions awkward.

> "I know what every invisible character in my code is"

Wouldn't that be possible even when (exclusively) using tabs for indenting? Admittedly it's been a hot minute since I last programmed and I'm far more familiar with borland's ide with turbo c++ than VS code (so I don't know what the latest formatting works/features are), but if you only indent with tabs isn't that good enough? Also, do multiple spaces not take much more time to type out? Or have you remapped your tab key to multiple spaces?

> We have huge screens, we're not in the 80s anymore

Unless you have huge peripheral vision too, your screen is likely not the issue.

Ha, ha. When I first sat on a (then new) 24" wide screen (I remember when 19" CRTs where huge), I actually experienced something alike vertigo. Happened never again, but I haven't tried one of those concavely curved monitors yet ...

this thing in portrait mode might do the trick: https://youtu.be/CsoKWsZ-Tyw?si=LkUHiqIF429v8h6Y

Zero chance of a problem like in the post happening in the first place.

Same reason I multiply all my integers by 4 in the setter and divide by 4 in the getter.

You just used 4 of them …