← Back to context

Comment by fc417fc802

15 hours ago

I don't see why? Your window width will presumably be tailored to accommodate common scenarios in your preferred tab width.

More than that, in the general case for common C like languages things should almost never be nested more than a few levels deep. That's usually a sign of poorly designed and difficult to maintain code.

Lisps are a notable exception here, but due to limitations (arguably poor design) with how the most common editors handle lines that contain a mix of tabs and spaces you're pretty much forced to use only spaces when writing in that family of languages. If anything that language family serves as case in point - code written with an indentation width that isn't to one's preference becomes much more tedious to adapt due to alternating levels of alignment and indentation all being encoded as spaces (ie loss of information which automated tools could otherwise use).

I find it tends to be a structural thing, Tabs for indenting are fine, hell I prefer tabs for indenting. But use tabs for spacing and columnar layout and the format tends to break on tab width changes. Honestly not a huge deal but as such I tend to avoid tabs for layout work.

  • I love the idea of "tabs for indents, spaces for alignment", but I don't even bring it up anymore because it (the combination of the two) sets so many people off. I also like the idea of elastic tabs, but that requires editor buy-in.

    All that being said, I've very much a "as long as everyone working on the code does it the same, I'll be fine" sort of person. We use spaces for everything, with defined indent levels, where I am, and it works just fine.

  • I completely agree, hence my point about Lisps. In terms of the abstraction a tab communicates a layer of indentation, with blocks at different indentation levels being explicitly decoupled in terms of alignment.

    Unfortunately the discussion tends to be somewhat complicated by the occasional (usually automated) code formatting convention that (imo mistakenly) attempts to change the level of indentation in scenarios where you might reasonably want to align an element with the preceding line. For example, IDEs for C like languages that will add an additional tab when splitting function arguments across multiple lines. Fortunately such cases are easily resolved but their mere existence lends itself to objections.