In languages that don't allow trailing commas, I prefer this comma-first style. It makes it easy to avoid missing or extra commas, which shortens my feedback loop a bit. But I usually don't use it, because a lot of people react the way you do, and I want you to be able to read and enjoy my code despite your irrational and bizarrely extreme prejudice.

I had never really thought about commas that way, but I can totally get why someone would want to use this style now. Thank you for taking the time to explain it!

I've noticed this formatting in sql scripts before too - the biggest benefit I see is making source control diffs only show one line changed rather than two when adding/removing lines.

Unless you're inserting as the first line ...

The benefit (compared to more classic formatting) only occurs if you're inserting at the end of the argument list.

If adding stuff to the end of a class or of an argument list is your most frequent case, you might have a software design problem.

Is that a benefit?

Yes. When you git blame a line you won't get a commit just adding/removing a comma changing on that line.

Some languages/DSL's allow for a comma at the end of the list too, thereby getting the same result but without the slightly strange comma at the start of the line. Adding additional lines is simple then and doesn't cause the line above to be pulled in to any git action

Maybe git blame should get better.

What’s bonkers specifically? Is the the leading commas, alignment, one identifier per line, capitalization, long names, same line braces, something else?

FWIW, everything seen here has options in Clang Format: https://clang.llvm.org/docs/ClangFormatStyleOptions.html

Personally, I like what this looks like. Leading commas are nice in situations where the first argument is fixed, but the remaining arguments move a lot while I’m tweaking & refactoring. I also like leading operators in long multi line math expressions, it’s easier to see at a glance how everything is combined when the operators are in front. I also like seeing arguments aligned, it’s easier to spot mistakes, easier to move things around, easier to use column selection, etc.

I rarely actually use the formatting I like because at work my team uses clang format so we’re standardized. Despite whatever formatting opinions I like, I love not arguing about formatting and having the formatter dictate and handle it for everyone.

I write this way to make it easier to see when I’ve missed a comma, and also for editor macros.

I’ll often reformat when I’m done so it fits our code review style.

Also I’m usually working systemverilog so 5-10 parameters are common and 50 or more isn’t rare.

If you do a lot of adhoc sql with an editer that supports multiline editing, it allows for pasting in big lists of text and quickly formatting it, trailing commas and ragged edge right data suck to edit in bulk.

I see that occasionally in my works codebase. I don't mind it so much. Sometimes I'll see

    If(predicate
       && nextPredicate
       && lastPredicate)
    {
        DoStuff();
    }

Which I don't mind but also don't write. However, I do prefer ternary expressions like

    int someNum = somePred
        ? firstVal + 42
        : 1000;

It's a hacky workaround for languages that don't support trailing commas

And more widely; languages that burden the programmer with such extraneous grammar in the first place.

Reminds me of how Elm lists are formatted; I have a hunch it may be something more common in Haskell, but that's pretty much a shot in the dark.

Yeah this is Haskell formatting

The part that has me twitching are the magic numbers in the calls to generateLightColorPart :P