@enkiv2 I've always been a spaces partisan, but this is convincing to me.

I've always preferred tabs, especially after learning how they can be used in such a way as to /not/ lead to ragged source listings while still letting others pick their preferred tabstop. (Hint: it's codified in how gofmt formats code.)

AFAICT, there's no reason not to use this approach except pure laziness, ableism, or naked chauvenism (c.f. "special snowflake tabstop" comment in the thread).

@vertigo @enkiv2 Unfortunately, Python, which I work in a lot, makes this very difficult. The official style guide (PEP 8) requires spaces-only for indentation, and the standard code formatting tools (such as black) enforce this. Mixing spaces and tabs can also be illegal in Python; it is okay as long as you have only tabs at the beginning of the line and spaces at the end and never go back and forth, but this introduces another place where things can go wrong.

@vertigo @enkiv2 I would try this with other languages I use, but with C# at work, indentation is basically controlled by the IDE, and is probably not configurable. And the other main language I use is Lisp, where the convention is also strongly to use spaces, so I would be going against the usage of most people who would be looking at my code.

@gcupc @enkiv2 I totally agree, and am under similar constraints. :(

@gcupc @vertigo @enkiv2
Yeah. I ignore any style standard I don't like (including python ones) but this doesn't fly so well with bigger / group projects.

@enkiv2 @gcupc @vertigo if you have a standard style format and a formatter, you could always add scripts to use that formatter to reformat with a different tabstop after checkout and go back before commits

@er1n @enkiv2 @gcupc @vertigo does that make diffing uncommitted changes difficult? I've always meant to try this but never had a good enough reason to

@lm @er1n @enkiv2 @gcupc When coding in Go, the usual practice is to invoke gofmt either before save or immediately after save, so that reformatting the source is automatic. Because of that, diffing uncommitted work is as effortless as in other workflows.

@vertigo @er1n @enkiv2 @gcupc right, but I'm curious about how reformatting code on checkout would affect diffs, manually resolving merge conflicts, and the like

@lm @er1n @enkiv2 @gcupc Forgive me; I'm confused. Why would one want to reformat code on check-out, if it was reformatted upon save prior to checking in? I guess to answer your question, I'd need to know what the code reviewer's objective was in reformatting on check-out.

@er1n @lm @enkiv2 @gcupc The Go-style of indentation resolves this, so obviates the need for local reformatting post check-out; the viewer selects their own tab width without modifying the source code. Basically, everything to the left of the first column of source code is tab-indented. Everything after that is space-indented for alignment. The only requirement is a fixed-width font (it won't work with proportional width fonts, regrettably).

@vertigo @gcupc @enkiv2 If the code formatter does it, that's perfect.

My one concern is that I'm an editor configuration minimalist, and editors generally are pretty bad at this unless you install the appropriate plugins/modes and spend time configuring them.
@gcupc @enkiv2 @vertigo

I guess I'm a tab person in theory, but a spaces person in practice.


> Other people are less likely to screw up spaces.

This and "tooling is bad" are the two hard practical arguments for spaces, I think. A code formatter would make that go away.

@clacke @gcupc @enkiv2 I think I fall into this category as well. I consider myself in my "pure laziness" category because I've grown tired of competing with corporate coding standards. And now that entire **language communitiess** have recommended coding conventions, almost all of which I find direly suboptimal in important ways, I've all but given up the good fight. *sighs* :(

@clacke @gcupc @enkiv2 We wouldn't have this damn problem in the first place if we just had a simple, yet just-structured-enough, widely adopted format for storing source listings.

GeoWrite format (for Commodore 64/128 platforms) comes the closest I've seen to this ideal. But, because it's not Unix, it'll never fly.

@vertigo @clacke @enkiv2 I mean, sexps are simple but structured enough, and we've had them since 1958 😜

@gcupc @clacke @enkiv2 Not quite what I meant. :) But, auto-layout in the editor upon load and compactification upon save would *entirely* obviate this argument in much the same way, I suppose. Where do I sign up?

@gcupc @enkiv2 @vertigo I guess having a linter that enforces line length is also a reasonable argument against tabs.


@clacke @gcupc @enkiv2 I can see the argument, but I'm not convinced that this matters much in practice; if you're nesting more than 4 deep, that's a code smell worthy of an intervention. Most code is indented 1 to 2 levels. Anything more than that is almost a dead giveaway that it's time to simplify/refactor the code. (Yes, I'm guilty of this as well; but regular code reviews can help here.)

@clacke @gcupc @enkiv2 Given that constraint, the line width argument holds merit only for narrow display devices only (e.g., 640 to 800 pixel wide screens). Contemporary displays are easily able to accommodate 90+ characters per column on screen, even on 1080p monitors.

@vertigo @clacke @enkiv2 on a 1080p monitor, you often want to look at two buffers side by side, for 960 pixels. Less if your environment has sidebars. This works great for lines under 90 chars, but that's about the limit.

@gcupc @enkiv2 @vertigo Yes, I find around 100 characters is a decent max for side-by-side on 1080p, 15 inch screen.

@vertigo @clacke @gcupc @enkiv2
What about data?
Eg.: deeply nested Lua tables in configs.

@grainloom @clacke @gcupc @enkiv2 I have exactly this problem with writing a scheduler intended to reconfigure a customer's solar inverter at various points throughout the year. 6-deep trees of configurations aren't uncommon.

The way I resolve this in practice is to assign one or two levels of nesting to variables, and then reference those variables in higher-level constructs.

I find it is substantially easier to work with in source code this way.

@grainloom @clacke @gcupc @enkiv2 Where this falls flat is in JSON-formatted files, as they don't allow for variables. >:/ In situations such as this, well, I've been heard down the hall cursing vociferously by my C-level bosses.

@clacke @gcupc @enkiv2 @vertigo
Line length restrictions ought to default to treating tab as a single character because anybody with a display small enough / a font large enough to really care about the 80 character (or 40 in the case of braillers) boundary will be setting it that way...

@clacke @gcupc @enkiv2 I've done this without any plugins by hand. It's not hard to do. Just hard to habituate. But once it's habitual, it's no more difficult than normal editing practices.

Over the years and through routine exposure to Ruby and Python code bases, I've grown to be "pure lazy" in my categories above, so I'm no moral authority here. But, there was a time when I wrote code like that pretty religiously, and it wasn't onerous at all.

@clacke @gcupc @enkiv2 @vertigo
You could always do it independent of your editor.
Something like:
while (true) {

@gcupc @enkiv2 Ditto.

> Regarding Github, you can set a default rendering tabstop with an .editorconfig in a repository, and override with ?ts=<value> in URLs.

Whaat that's awesome.

> 'consistency across environments' is exactly the problem for these guys, they have different needs

I really wish more devs and web designers understood this and stopped trying to force people to view their GUIs / websites the same way

@grainloom @enkiv2

so many people: "Wow I love the font on your website!"

me: "that's your system's configured font. I'm glad you like it!"

@emsenn @grainloom @enkiv2
Yeah, absolutely. My take on tabs vs spaces is basically that, no matter what the reason, a code author shouldn't be able to boss code users / readers around, & accessibility is just an elevated subset of that.

@grainloom @enkiv2 I frequently encounter websites which simultaneously strive to be mobile-only (as a means of cheaply achieving goals of mobile-first design compliance) and a replacement for glossy print media. Even without needing to navigate these sites to a deep level, I find these are routinely the most infuriating websites to use. :(

Glitz-Driven Development. #NotEvenOnce.

LB : j'aime pas les tabs dans le code mais bon à ce stade je suis bien forcée d'admettre que c'est une préférence perso dont je vais devoir forcer à me débarrasser (sauf qu'à mon boulot pour l'instant il faut des espaces)

@changelin @enkiv2 yes I agree, but most of modern IDE now understand spaces as tabs and are able to format them to be more or less wide depending on the user settings. I will try to find it in my IDE tomorrow.

Sign in to participate in the conversation
Eldritch Café

Une instance se voulant accueillante pour les personnes queers, féministes et anarchistes ainsi que pour leurs sympathisant·e·s. Nous sommes principalement francophones, mais vous êtes les bienvenu·e·s quelle que soit votre langue.

A welcoming instance for queer, feminist and anarchist people as well as their sympathizers. We are mainly French-speaking people, but you are welcome whatever your language might be.