4 ms·

Because the latter is universal, and it can always align perfectly. # using tabs with tabsize 4 some_func( eyesore, blah );

Because the latter is universal, and it can always align perfectly. # using tabs with tabsize 4 some_func( eyesore, blah ); some_func( eyesore, blah ); some_func( eyesore, blah );

SoftTalker 1y ago
Well, obviously tabs should always be 8 spaces.
- daneel_w 1y ago
  Not sure if you're joking since 8 makes the whole problem even worse :)
Asooka 1y ago
We use 4-wide tabs and in our code style it would be some_func( verylongarg0, verylongarg1 ); Which I feel is the most readable option. If you have to break the args into a vertical list, you want to use the least amount of whitespace before each arg. It's also a bit easier to read with every term starting at a tab break.
- daneel_w 1y ago
  With a large set of arguments broken down to multiple lines I prefer to keep them clear of the function name. with_long_func_names( this_scheme, looks_muddled ); long_func_name( tidier, scheme ); But my main gripe with tabs is that no one agrees on the width.
  - mcdonje 1y ago
    Not agreeing on width is an argument in favor of tabs.
  - jdrek1 1y ago
    > But my main gripe with tabs is that no one agrees on the width. That's the entire point of tabs. One tab means one indentation level and you as the user can decide how that's displayed. Spaces forces everyone to see the code exactly as whoever decided on his favourite width and that is in the best case "only" annoying to people with different preferences and in the worst case actively hurtful to people with disabilities. The only argument spaces people ever have is "some of my colleagues are too stupid to properly indent with tabs and align with spaces" and that is trivially fixed by either of those: - don't use alignment, it's useless anyway - get better coworkers - educate your coworkers - use commit hooks to check wrong usage So basically there is no argument left on the spaces side at all^[1]. Meanwhile tabs semantically mean "one indentation level", take up less bytes, and most importantly allow everyone to have their own preferences without affecting other people. And honestly I am insanely baffled by how many people don't get the importance of that last part. Accessibility like that costs you nothing but means the world to other people, similarly how we have ramps at public buildings for the elder, wheelchair users, strollers, and so on. And not to mention the fact that there are a lot of autistic people in programming, which often have a harder time dealing with things not being as they want them to be. Is there any reason to choose an objectively inferior method and force that onto those demographics just because "muh alignment"? [1] Okay fine, there is one: "Tools I don't own don't display tabs as I want them, for example GitHub with their retarded default of 8". But first of all you can change that if you're logged in and second you're supposed to use your IDE and not a web interface...
    - Asraelite 1y ago
      I would agree that there aren't any arguments for spaces and would be 100% on the side of tabs, except for one problem: variable width means you can't enforce a maximum column limit. Some people don't care about column limits, but they're important to me because I like to tile multiple editor panes side-by-side with no space wasted. The entire debate is stupid anyway and should already be a solved problem. If we used tooling that operates on syntax trees instead of source text, then every developer could have exactly the formatting they want without conflicts. I don't know why that isn't more widespread; the only language I know of to do it is Unison.
  - creeble 1y ago
    The beauty is you don’t have to.
  - Vendan 1y ago
    that's the entire point of tabs, they can be customized to what the person reading them wants. It's an accessibility issue (https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/ https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...).
    - layer8 1y ago
      Both tabs and spaces can in principle behave any way a user would want in editors, at least for whitespace at the start of a line. In particular, an editor could have (suitable ranges of) spaces behave like tabs, or vice versa. However, almost no editor provides the full range of desired behaviors for both. For example, one thing I don’t like about tabs is that cursoring over them makes the cursor jump, and not proceed at constant speed horizontally. An editor could in principle have an option to not do those jumps, but barely any editor has.
  - layer8 1y ago
    That’s not invariant under refactor-renaming the function name. An invariant way of keeping the arguments clear of the function name would be: with_long_func_names ( this_scheme, looks_muddled ); Though it would take some getting used to intuitively recognizing that as a function call.
DaiPlusPlus 1y ago
> and it can always align perfectly. I'm firmly in Team Tab, and I want to arrest any misconception that us Tabbers would do anything as nonsensical as using our precious variable-width tab-stop chars for anything like column-aligning identifiers: we don't. My very hard and fast rule is that tabs are for only indenting at the block level, while spaces are used for alignment after the initial tab chars; tabs must never be used on a line if preceded by any non-tab char. Whereas I can't stand always-using-only-spaces-for-indenting-and-alignment - especially because when you're drag-selecting text most editors won't snap your selection to the indent level, so you get RSI in your wrist from having to make micro-movements to make sure you don't select more - or less - spaces than the intended indent. ...or worse: when moving the caret via the keyboard and having to tap your arrow-keys 4 or 8 times per indent instead of just once. You spaces-only people are totally spaced out, man.
- daneel_w 1y ago
  Sir, you are way out of alignment. Detabulate immediately.
- Cieric 1y ago
  I personally agree with this, but a lot of the tools out there break this easily. I'm curious if you have any tools that handle the formatting like this properly. I've written my own tool that will report invalid whitespace when following this, but it can't fix any of it automatically. The commonly used clang-format also messes up this scheme as it will convert alignment space to tabs.
  - DaiPlusPlus 1y ago
    I'll admit that I spend most of my time in Visual Studio which supports my preferences very well, including my .editorconfig (which is now the .editorconfig for my entire org... it's almost as if good ideas have a following ;) I do understand the appeal and advantages of having automated+opinionated re-formatting as part of a gated check-in process, because it's about having a normalized and consistent representation in the canonical repo; the idea being that you'd have a git-hook that would apply your own preferred formatting style on checkout which would be undone on commit; alas, we're not quite there yet. ...but having a single, normalized format (even if everyone hates it for different reasons) is the reason why gofmt and clang-format stick to spaces. I remember (back in 2017) being forced to submit to gofmt's dominion over my code and it ruining my beautifully aligned mass-assignments - and in my frustration I complained about this on StackOverflow and almost immediately someone replied with a working solution: use C-style comments to "protect" whitespace from being mangled by gofmt, see here: https://stackoverflow.com/questions/46940772/how-can-i-use-gofmt-to-align-parameters-and-assignment https://stackoverflow.com/questions/46940772/how-can-i-use-g... Also, apparently clang-format now supports tabs with some hoops: https://stackoverflow.com/questions/69135590/how-make-clang-format-indent-using-tabs-instead-of-spaces/73498815 https://stackoverflow.com/questions/69135590/how-make-clang-... - does that work for you?
zahlman 1y ago
My style using spaces is some_func( eyesore, blah ) which would work just as well with tabs. Many years ago, I used tabs, and set them to two-space indent. The former because the entire point is that tabs carry different semantic information - this is a level of indentation, not just making things align vertically - and allow each developer to set the indentation width to their preference. (The other comment from DaiPlusPlus explains the proper use of tabs, just as I did it.) The latter because that makes them more square. Aesthetics matter. I switched mostly out of peer pressure. But one argument I did find convincing is that setting some specific limit on line length - whether it's 72 or 78 or 80 or 100 or anything else - makes sense, and letting people change the amount of indentation defeats that purpose. That is: the guy who likes 8-space indents can't actually have them, because it produces a horizontal scroll for code that "conformed to the style guidelines" when written by the 2-space guy. But now I alias names, break up complex subexpressions etc. to avoid questions of how to split code across multiple lines - and most lines in my code are nowhere near any such length limit. And I write short functions, so there aren't enough levels of indentation to matter. And I use 4-space indents, because standards have value after all.

Because the latter is universal, and it can always align perfectly. # using tabs with tabsize 4 some_func( eyesore, blah ); some_func( eyesore, blah ); some_func( eyesore, blah );

SoftTalker 1y ago

Well, obviously tabs should always be 8 spaces.

daneel_w 1y ago
Not sure if you're joking since 8 makes the whole problem even worse :)

Asooka 1y ago

We use 4-wide tabs and in our code style it would be some_func( verylongarg0, verylongarg1 ); Which I feel is the most readable option. If you have to break the args into a vertical list, you want to use the least amount of whitespace before each arg. It's also a bit easier to read with every term starting at a tab break.

daneel_w 1y ago
With a large set of arguments broken down to multiple lines I prefer to keep them clear of the function name. with_long_func_names( this_scheme, looks_muddled ); long_func_name( tidier, scheme ); But my main gripe with tabs is that no one agrees on the width.
- mcdonje 1y ago
  Not agreeing on width is an argument in favor of tabs.
- jdrek1 1y ago
  > But my main gripe with tabs is that no one agrees on the width. That's the entire point of tabs. One tab means one indentation level and you as the user can decide how that's displayed. Spaces forces everyone to see the code exactly as whoever decided on his favourite width and that is in the best case "only" annoying to people with different preferences and in the worst case actively hurtful to people with disabilities. The only argument spaces people ever have is "some of my colleagues are too stupid to properly indent with tabs and align with spaces" and that is trivially fixed by either of those: - don't use alignment, it's useless anyway - get better coworkers - educate your coworkers - use commit hooks to check wrong usage So basically there is no argument left on the spaces side at all^[1]. Meanwhile tabs semantically mean "one indentation level", take up less bytes, and most importantly allow everyone to have their own preferences without affecting other people. And honestly I am insanely baffled by how many people don't get the importance of that last part. Accessibility like that costs you nothing but means the world to other people, similarly how we have ramps at public buildings for the elder, wheelchair users, strollers, and so on. And not to mention the fact that there are a lot of autistic people in programming, which often have a harder time dealing with things not being as they want them to be. Is there any reason to choose an objectively inferior method and force that onto those demographics just because "muh alignment"? [1] Okay fine, there is one: "Tools I don't own don't display tabs as I want them, for example GitHub with their retarded default of 8". But first of all you can change that if you're logged in and second you're supposed to use your IDE and not a web interface...
  - Asraelite 1y ago
    I would agree that there aren't any arguments for spaces and would be 100% on the side of tabs, except for one problem: variable width means you can't enforce a maximum column limit. Some people don't care about column limits, but they're important to me because I like to tile multiple editor panes side-by-side with no space wasted. The entire debate is stupid anyway and should already be a solved problem. If we used tooling that operates on syntax trees instead of source text, then every developer could have exactly the formatting they want without conflicts. I don't know why that isn't more widespread; the only language I know of to do it is Unison.
- creeble 1y ago
  The beauty is you don’t have to.
- Vendan 1y ago
  that's the entire point of tabs, they can be customized to what the person reading them wants. It's an accessibility issue (https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/ https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...).
  - layer8 1y ago
    Both tabs and spaces can in principle behave any way a user would want in editors, at least for whitespace at the start of a line. In particular, an editor could have (suitable ranges of) spaces behave like tabs, or vice versa. However, almost no editor provides the full range of desired behaviors for both. For example, one thing I don’t like about tabs is that cursoring over them makes the cursor jump, and not proceed at constant speed horizontally. An editor could in principle have an option to not do those jumps, but barely any editor has.
- layer8 1y ago
  That’s not invariant under refactor-renaming the function name. An invariant way of keeping the arguments clear of the function name would be: with_long_func_names ( this_scheme, looks_muddled ); Though it would take some getting used to intuitively recognizing that as a function call.

DaiPlusPlus 1y ago

> and it can always align perfectly. I'm firmly in Team Tab, and I want to arrest any misconception that us Tabbers would do anything as nonsensical as using our precious variable-width tab-stop chars for anything like column-aligning identifiers: we don't. My very hard and fast rule is that tabs are for only indenting at the block level, while spaces are used for alignment after the initial tab chars; tabs must never be used on a line if preceded by any non-tab char. Whereas I can't stand always-using-only-spaces-for-indenting-and-alignment - especially because when you're drag-selecting text most editors won't snap your selection to the indent level, so you get RSI in your wrist from having to make micro-movements to make sure you don't select more - or less - spaces than the intended indent. ...or worse: when moving the caret via the keyboard and having to tap your arrow-keys 4 or 8 times per indent instead of just once. You spaces-only people are totally spaced out, man.

daneel_w 1y ago
Sir, you are way out of alignment. Detabulate immediately.
Cieric 1y ago
I personally agree with this, but a lot of the tools out there break this easily. I'm curious if you have any tools that handle the formatting like this properly. I've written my own tool that will report invalid whitespace when following this, but it can't fix any of it automatically. The commonly used clang-format also messes up this scheme as it will convert alignment space to tabs.
- DaiPlusPlus 1y ago
  I'll admit that I spend most of my time in Visual Studio which supports my preferences very well, including my .editorconfig (which is now the .editorconfig for my entire org... it's almost as if good ideas have a following ;) I do understand the appeal and advantages of having automated+opinionated re-formatting as part of a gated check-in process, because it's about having a normalized and consistent representation in the canonical repo; the idea being that you'd have a git-hook that would apply your own preferred formatting style on checkout which would be undone on commit; alas, we're not quite there yet. ...but having a single, normalized format (even if everyone hates it for different reasons) is the reason why gofmt and clang-format stick to spaces. I remember (back in 2017) being forced to submit to gofmt's dominion over my code and it ruining my beautifully aligned mass-assignments - and in my frustration I complained about this on StackOverflow and almost immediately someone replied with a working solution: use C-style comments to "protect" whitespace from being mangled by gofmt, see here: https://stackoverflow.com/questions/46940772/how-can-i-use-gofmt-to-align-parameters-and-assignment https://stackoverflow.com/questions/46940772/how-can-i-use-g... Also, apparently clang-format now supports tabs with some hoops: https://stackoverflow.com/questions/69135590/how-make-clang-format-indent-using-tabs-instead-of-spaces/73498815 https://stackoverflow.com/questions/69135590/how-make-clang-... - does that work for you?

zahlman 1y ago

My style using spaces is some_func( eyesore, blah ) which would work just as well with tabs. Many years ago, I used tabs, and set them to two-space indent. The former because the entire point is that tabs carry different semantic information - this is a level of indentation, not just making things align vertically - and allow each developer to set the indentation width to their preference. (The other comment from DaiPlusPlus explains the proper use of tabs, just as I did it.) The latter because that makes them more square. Aesthetics matter. I switched mostly out of peer pressure. But one argument I did find convincing is that setting some specific limit on line length - whether it's 72 or 78 or 80 or 100 or anything else - makes sense, and letting people change the amount of indentation defeats that purpose. That is: the guy who likes 8-space indents can't actually have them, because it produces a horizontal scroll for code that "conformed to the style guidelines" when written by the 2-space guy. But now I alias names, break up complex subexpressions etc. to avoid questions of how to split code across multiple lines - and most lines in my code are nowhere near any such length limit. And I write short functions, so there aren't enough levels of indentation to matter. And I use 4-space indents, because standards have value after all.