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 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.
Thank God I did not break my pinky.
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.
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.
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.
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.[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_...
Newbies editing code is a problem best solved with automatic formatting.
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.It's just that sooner or later someone will get it wrong.
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~
This is no worse than using 4 spaces to indent. Using 2 or 8 or 3 spaces for a tab is a skill issue.
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.
Tabs are self-consistent, which is usually all that matters. If for some reason you need greater control (E.G. ASCII-art spanning multiple indentation levels), then that should be documented instead.
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
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.
Unless you have huge peripheral vision too, your screen is likely not the issue.
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.
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?