Programming

17378 readers

585 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Elastic tabstops: A better way to indent and align code (nickgravgaard.com)

submitted 1 year ago by JackbyDev@programming.dev to c/programming@programming.dev

7 comments fedilink hide all child comments

Archived link.

I think this is a good read to learn about what tabs and tabstops really are regardless of whether you agree that tabstops should be at different positions per line or with the controversial idea of using proportional fonts (this would work with monospaced fonts too).

you are viewing a single comment's thread
view the rest of the comments

[–] JackbyDev@programming.dev 5 points 1 year ago (3 children)

I will open the comments with the most obvious negative. A lot of people avoid tabs altogether and only use spaces because it is difficult to adjust tabstop positions (the technical term for tab width in this context, see the article) and you want everyone to have the same viewing experience or at least be able to customize it properly if the source uses tabs. One common argument for tabs is that you can modify the tabstops, but it is difficult enough or impossible in enough tools that some people who agree this is good still prefer spaces. What Elastic Tabstops is proposing is not just relating to tabstops (which are poorly supported sometimes as just mentioned) but also proposing an entirely new way to render them. The arguments against tabs in general are only amplified because so few tools would properly display them. The article mentions this was first proposed in July of 2006. Next month that's going to be 17 years. Still no tools support this out of the box to my knowledge. There is sadly too much collective inertia behind traditional tabstops.

All that said, I have a soft spot for this concept and would really love to see it catch on.

[–] in2erval@kbin.social 3 points 1 year ago* (last edited 1 year ago) (2 children)

In some of my personal code I liked to have used it (in very specific circumstances, like having many similar-sized parameter declarations e.g. protobuf), but as you said the lack of support means that a lot of code formatters simply trim unnecessary spaces so they never stick around.

What's more, I am still yet to find a consistent rule about when to apply this kind of formatting - the example in the article shows one for method args but it just doesn't look good at all. Key-value lists (like maps) might be a good place to use it, but if one key ends up being very long you have a ton of unnecessary space, so I would need to "group" together similar-length keys to make it aesthetically pleasing:

const map = {
  foo:    1,
  bar:    2,
  bazbar: 3,

  // I don't want the keys above to be spaced to match this key
  someExtremelyLongKeyname: 4
}

[–] JackbyDev@programming.dev 1 points 1 year ago (1 children)

Yeah, I personally don't like aligning key value pairs all the time (maybe rarely I do). The most compelling example is putting a tab before end-of-line comments. Also it would make tab delimited CSV files render more easily.

[–] in2erval@kbin.social 1 points 1 year ago

To me it feels like this would work nicely for something that's more tabular in nature, such as you mentioned, CSVs. But again, not all the time, which makes this formatting hard to use.