1. 4
  1. 7

    I just write ugly long lines of code and then my editor can do the indenting and formatting for me, using project/language-specific configs/tools, and I don’t have to care or type as much.

    1. 3

      Yeah, for Python there are things I don’t like about black, but the fact that it just ends all arguments is priceless; I don’t even think about formatting, just let black run automatically every time I save a file.

      1. 2

        As the documentation for go fmt states: “it’s everyone’s favorite format and everyone’s least favorite format.”

      2. 2

        That’s great as long as no one else reads your code in a different editor. I’ve used this style for almost 20 years now. I can use ts=4 in vim, someone else can use cat or diff with the default 8-character tabs, someone who prefers denser code can set their tab width to 2, and it all works fine. If I wanted to achieve this with automatic indenting tools then I’d need to be able to guarantee round-tripping: if I set the indent size to 4 spaces and run the auto formatter, then you set it to 2 run it, and then set it back before commit, will you get any whitespace changes? This stability is not always guaranteed by such tools.

        Note: clang-format now has a UseTab: ForIndentation setting that does indentation with this style, which means that you can just configure your editor to use this style and forget about it.

        1. 1

          Any other editor using zig fmt, .editorconfig, or whatever the project uses should produce the same results.

          If it doesn’t, or if it’s a multiplayer project that really has no such thing (and doesn’t want it), then I would have to adapt to that, but so far so good.

          1. 1

            Any other editor using zig fmt, .editorconfig, or whatever the project uses should produce the same results.

            That’s the point. It’s fine if they want the same results. If they want to edit the code with four-character-wide indentation but your style is defined to use two spaces, or to use tabs but assume that the tabulators are set to eight-character indexes, then they just have to live with that decision.

            If you use tabs for indentation and spaces for alignment (and set your formatting file to use this style, for autoformatting, as clang-format can now do) then they can choose the indent width in their editor and things don’t break.

            1. 1

              At a certain point, working with others — in an open-source project, in a team at your company, anywhere — means accepting that sometimes you will be out-voted and need to live with it.

              For example: for writing tests in Python, I personally strongly prefer the standard-library unittest module and don’t much like the third-party pytest module. In my own personal projects I use unittest (or Django’s wrappers around/additions to it). But every company I’ve worked at for the past 7 years has had a team where the majority wanted to use pytest. So I’ve used pytest at work.

              Which is to say: I think you probably should learn to live with the fact that your preferred indentation approach has been outvoted, and so when you are working with others you probably will need to adopt an indentation style that is not the one you personally prefer.

              1. 1

                I think you probably should learn to live with the fact that your preferred indentation approach has been outvoted, and so when you are working with others you probably will need to adopt an indentation style that is not the one you personally prefer.

                You have two choices as a project:

                • Pick an indentation style that you like and force everyone to use it, which guarantees that some people will be unhappy with the indent width.
                • Pick an indentation style that lets anyone pick their preferred indent width without negatively impacting anyone else.

                I really struggle to understand why anyone would defend the first option. Why would you choose to inflict a worse experience on other people when it’s completely avoidable?

                This is particularly jarring when you work on multiple projects. I contribute to some projects that have chosen option 1 and set the indent to 8 characters, others that have chosen option 1 and set the indent to 2 characters. If both projects had chosen option 2 then switching between them would not change my indent width.

                A few years ago I had a student work on a project called Code Editing in Local Style that took this even further and let you use your preferred capitalisation scheme or declaration style locally, while applying the upstream style when you committed. I’d love to see more tooling support this kind of mode. Capitalisation is particularly annoying in C++ where the standard library uses conventions that everyone agrees are stupid and so are not used by any other large library and it would be great to be able to transparently adapt these things syntactically on import.

              2. 1

                I was writing from the perspective of a project defining the style, not me.

                If someone doesn’t like the style of a certain project, and cares a whole lot about it, I’m sure that sucks.

                I’m only saying that personally I don’t care so applying the project style automatically is great for me. Even if it’s not what I would have chosen if I set it up myself. When I do that I just go with the defaults of the tool.

        2. 1

          could this work for lisp? or is lisp basically just space bound?

          1. 2

            Works fine for lisp, if you have a lisp style that believes in indentation. Some lisp styles are all alignment all the time in which case using spaces technically complies with this, but not in an awesome way.

            1. 1

              well now I feel like I need to research lisp indentation schemes!