4 ms·
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.
by Dibby053 2y ago
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.
- MrJohz 2y agoThen 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.
- yencabulator 2y agoBy your definition, all Go code in the world is madness? Newbies editing code is a problem best solved with automatic formatting.
- smallstepforman 2y ago“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”.
- okanat 2y agoThat 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.
- outop 2y agoYou 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.
- autumn-antlers 2y agoThis 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/ 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~