Java for sure. I don't think Google style is good enough to be called the default.

Somehow it doesn't seem to be such a big problem in Java land. I think there's some common baseline shared by basically everyone - I don't remember ever seeing Java classes which were not indented with 4 spaces for example.

Yeah, this dates back pretty far: https://www.oracle.com/technetwork/java/codeconventions-1500...

While minor variations exist, virtually all Java code follows these conventions pretty closely.

Although I'll note it seems to get a bit more chaotic with regards to indenting newer constructions like streams and lambdas.

People like to pooh pooh Java in the circles I hang out in, but I’m always quick to point out stuff like this, things that are just basically mostly solved in Java land and no one really wastes time on anymore because some pretty good decisions were made 20-25 years ago. How to handle a lot of aspects of dependencies is another classic example.

Auto-formatting is also used for enforcing a line width limit while keeping the code readable, which is hard and tedious to do manually.

C(++). There is clang-format which has good defaults, but it's highly configurable.

clang-format has so many useless options and yet it cannot do normal readable argument handling. At least not according to the documented options (as of a few versions back at least).

    function(
        arg,
        arg
    );

New line per argument, closing parenthesis on a new line. This is standard in most langauges, yet clang-format cannot handle it.

Then it also insists on aligning everything prettily. Most, but not all of it can be disabled though.

And lastly it doesn't do very well with tab indents. Most of it works perfectly, you just need to set both tab size and indent size, but then it decides to do its alignment thing and suddenly that line is all spaces, even the base indent.

Clang-format is honestly by far the worst formatter I've had the displeasure to fight. C/C++ still needs to be formatted manually

I think with this kind of stuff, it should be, give me a sane set of defaults and make me change it when they don’t make sense. Rather than go to make me search and configure and have to make 100 different decisions on minutiae and exhaust my brainpower on what I would consider important but relatively low impact work in the short term

Sounds like {AlignAfterOpenBracket: BlockIndent, BinPackArguments: false}

(EDIT: Newlines in the code example)

Oooh, that's much closer. Not perfect, but so much better. Do you have a solution for this as well?

    →(StructType){
    →····.a = 1,
    →····.b = 2,
    →};

It's not just this scenario, but this is the worst one. It does it regardless of useTab and what's worse is that it's four spaces when both indent width and tab size are set to 8

Weirdly, initializer indentation is controlled by `ContinuationIndentWidth` rather than by `IndentWidth`. That one I would agree is a clang-format bug, or a mistaken policy decision.

I haven't myself worked on a tabbed code base during clang-format's existence. You might want to look at Linux's settings for ideas, although they clearly differ from your preferences in other ways. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Seems like the point of this is to work across languages though. I'm not sure how I feel about it. Different languages have their own conventions. Often times there's a reason why one convention might be preferred in a language over a different convention in another

Elm even comes packaged with it's own auto-formatter

I really like the batteries included philosopy. I think golang really took the idea mainstream but deno, heavily inspired by go and that philosophy, also is a joy to use.

One of Haskell's most popular formatters, Formolu [1], is explicitly not opinionated and has custom whitespace as a goal:

> Let some whitespace be programmable. The layout of the input influences the layout choices in the output. This means that the choices between single-line/multi-line layouts in certain situations are made by the user, not by an algorithm. This makes the implementation simpler and leaves some control to the user while still guaranteeing that the formatted code is stylistically consistent.

Coq, Agda, etc. also don't have formatters either, partly because "user-defined layout", but also partly because their syntax is just so complicated and they have smaller ecosystems

[1] https://hackage.haskell.org/package/fourmolu