Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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_t...).


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.


Not agreeing on width is an argument in favor of tabs.


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.


The beauty is you don’t have to.


> 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...


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.


Why can't you just have a linter or a hook check that (tabs*2 + chars) < $defined_width


Because a coworker might want (tabs*4 + chars) < $defined_width. Whatever multiplier you pick, it will either mean a too short or too long limit, and inconsistent limits between lines depending on how much indented a line is, if everyone uses a different tab size.


Parent comment edited I think,

But I was addressing the the issue if enforcing column widths in a shared code base. I interpreted their statement as something like "you can't enforce column width in a code base with tabs".

But if someone changes their tab width, it's easy to check if it goes over 80, given a standard of 2 space tabs, and they use 1. Is they don't indent enough, that's harder.

I personally reformat code temporarily depending on what I'm doing, column width to me is a publishing standard, I don't care about it while I'm deep in the code.


Before the parent's edit it was about line length limits, IIRC. In any case that's what my comment was referring to. If you want to limit line length to, say, 100 characters (to visually fit within a 100-character wide window or terminal), then it matters what tab width you use. If you check it assuming a tab width of 8, someone working with a tab width of 2 will be limited to shorter lines the deeper the indentation level. Conversely, when the check assumes a tab width of 2, someone working with a tab width of 8 is likely to see lines longer than 100 characters although the lines passed the check.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: