There exists a formatting that has none of these problems. I’m of course talking about the self-evident pythonic/rustic formatting (which probably has many more names):

Yes, and that style usually contributes to files being overly long and sparse. It is not the panacea and many developers (including myself) don’t prefer that style when having more things on the screen is more valuable.

I remember a time before clang-format: I would say that professional developers did at least as good of a job as clang-format to begin with.

Hahahahaha. No. I also remember the time where other developers checked things in with their customized tab-width and used spaces for alignment on top of tabs for indentation. I do not wish to go back to that time.

In fact, in some ways better than any autoformatter could ever come up with, because the human knows best,

I’m happy that you haven’t met some people I’ve worked with.

Freedom of expression!

What.

If the purpose of automatic formatting is to avoid style disputes in code review, it doesn’t work, because too few people know the importance it gives to trailing comma – I have to nag people about it.

Instead of being glad that it’s the only thing you have to fight over, you choose to complain because clang-format doesn’t solve everything and anything.

I’ll give you point 3 in that it would be nice to give the option to have non-dependent syntax in clang-format for those who want it.

If you haven’t noticed the trend, everything is wrapped in impenetrable all-encompassing dockerized CI-scripts that can’t just check a small change quickly.

Sounds like a you issue. Our pre-commit linters at work finish in a couple seconds.

I find your rant to be opinionated and not considerate of the other side of the aisle. By all means, feel free to fork clang-format to adjust it to your needs, but to complain without considering the environment which spawned clang-format (many different C++ projects with wildly different standards had to be appeased for adoption) is ignorant.

This seems like a misplaced rant against coworkers who don’t format things with trailing commas like the author would like, and weird tooling issues (I certainly don’t run clang-format via Docker and can’t imagine why I would), rather than much of a criticism of clang-format itself. Even the “self-evident” example is a format that clang-format can and does use! Eliminating the comma “trick” would just mean you have even less control over formatting, which contradicts the point.

The main reason people (myself included) like machine-dictated formatting is to reduce/eliminate time wasted on bikeshedding. If the main issue is that developers won’t place a comma to your liking, not using an automatic formatter certainly isn’t going to make anything better: that just means there are many, many more things that other developers can do that isn’t to your liking.

This sort of thing easily gets toxic even in corporate environments where developers are expected to deal with their coworker’s nitpicks (because they get paid at least in part to do so), and is practically a non-starter in an open source context where you simply are not going to get submissions in exactly the style you want. You can then either manually reformat it all yourself, or berate people for it, certainly just driving potential contributors away. That is the main point of automated formatting, not “it always makes the code as pretty as possible”. clang-format is popular because it’s more or less Good Enough for everyone to tolerate, not because it’s anyone’s ideal, and having a tool to do that job eliminates a ton of wasted time which can be spent on something actually important.

I have the same issue with rustfmt. It does what people imagine gofmt doing, but not what it actually does.

gofmt is an error-fixing formatter. It fixes things about formatting it knows are wrong (like braces, indentation), but leaves everything else more or less unchanged (like 1-line vs multi-line choice). There are many ways to format the same construct, and gofmt respects humans’ high-level choice about the “layout” of the code.

Most other formatters are destructive canonicalizers, which completely replace formatting of the input with their own heuristics. The difference between these approaches is very significant, because reformatting based on heuristics doesn’t leave room for common sense, and bulldozes over formatting exceptions.

Unfortunately, these unforgiving blunt tools are still used due to the fallacy of “we must do something; this is something; therefore we must do this”.

I feel the same way. I want to like formatters but at the end of the day I find that human logic is really the best. Formatters tend to focus on unimportant things like line-length. What I care about is line complexity, I want to keep each line having one, maybe two ideas. No formatter can understand that.

I don’t mind some basic formatting such as brace style and fixing indentation but after much more than that I find it is putting things onto one line when it shouldn’t or vice-versa. I think things like clang-format have tried to take on too much and really make all code look the same. But I’ve never been confused by code because it used a+b rather than a + b.

I used to have a lot of opinions about code formatting, but over the years they’ve been hollowed out to just one: All of the code in a particular language within the scope of a project or organization should be formatted consistently and automatically with the same tool, preferably at the editor level but definitely enforced at check-in. I think Black and gofmt beat any other opinions I might have out of me.

I do think that most of clang-format‘s built-in styles are ugly in various ways, and once wasted a bunch of time trying to make a .clang-format that made it look more like Black. In retrospect, I wish I hadn’t, because the output still isn’t 100% to my particular taste. I have also possibly raised the barrier to entry to contributing to the project I did that on because now the code doesn’t look like any other extant project.

Formatters like Black and gofmt offer me zero decisions to make, so I just get down to coding and learn to love the formatter. clang-format offers me several choices, so I spend a bunch of time making (possibly incorrect) decisions about things that are ultimately inconsequential - “Let’s compare all of the built-in style to see which one I like best! Oh I kind of like C, but I really like the way A formats foo better - let’s see if we can tweak it!” – 4 hours later, much work has been done, but nothing of value has been accomplished.

aspects of code formatting that contribute to write amplification – how big a change becomes in the resulting diff

I love code formatters, but this problem is my pet peeve. When I choose a coding standard for a new project, my top priority is choosing a flavor that avoids write amplification. A standardized format is great, but not if it interferes with code review. I’ve encountered too many bugs hiding inside a diff hunk that was 90% auto-formatting noise. (I’ve had no luck with diffs that hide white space changes.)

in some ways better than any autoformatter could ever come up with, because the human knows best

I agree that a conscientious developer can format code better than a machine, at the margin. However, I’ve not found the marginal improvement to be worth the marginal cost in developer time/attention. A machine can format code 90% as good as a human in 1% of the time. Something like reformatter for emacs automatically reformats the buffer when I save it, so I spend almost no time on layout at all. I enjoy the way it lets me stay in flow.

It’s also the case that not all programmers are human. Maybe it’s a fancy refactoring tool or maybe it’s a lazy Perl script to munge away a recently discovered anti-pattern. Either way, they’re terrible at formatting. Having a human reformat this code manually gets expensive. Of course, non-conscientious developers who format at random also border on non-human :-)

Semantic diffing would obviate a lot of those objections. If we have fancy tools that understand language syntax to remove whitespace around, why shouldn’t the tools that show changes also understand syntax and weed out whitespace noise? I recall seeing links here to at least two such tools lately.

That said, minimizing diffs is not one of my top criteria for a coding style. Ease of reading is probably the first, primarily alignment. Then there’s not wasting too much vertical space, and a sensible line length (100 IMHO) because when an editor soft-wraps lines it really messes up readability.

If I understand, this is about the formatting style choice of having indentation on continuation lines align with similar elements on the preceding line. This is a common style and something I always avoid. A small change will often result in an entire block needing a change in indentation because the length of whatever was on the first line has changed. It also feels inconsistent because you get variable amounts of indentation (why indent a wrapped while condition more than a wrapped if). And often it pushes things far over to the right. And column alignment is only sometimes appropriate.

Where it is useful to be able to discern continuation lines from normal indentation, just use double the normal indentation amount. My vim setup applies this and I’m not especially aware of having ever configured it that way.

Another problem no one’s mentioned yet is performance. At work we use formatters on large generated files, and we’re having a lot of trouble with clang-format (https://fxbug.dev/78303). On my MacBook Pro, it can format 1 MB/s but the max RSS also scales linearly at 150x file size. So formatting a 1 MB file takes 150 MB of memory. The clang++ parser deals with these files without that memory blowup. My teammate @ianloic is trying to optimize some of clang-format’s data structures.

(Why format generated code? Because people can jump-to-definition and read it. Why generate huge files? We’re also working on splitting or shrinking, but these sizes aren’t unusual compared to e.g. protobuf, thrift.)

Copied from r/programing:

A few months ago I identified two categories of code format tools: at one end of the spectrum we have rule enforcers, and at the other end we have canon enforcers.

With rule enforcers, we have a set of rules the code must adhere to, and anything that breaks those rules is incorrect, but within the confines of those rules, you can do whatever you please. For instance, assuming lines are limited to 25 characters, the following would be incorrect:

void foo(int a, int b, int c, int d)
{
    int bar = a + b - c * d;
}

On the other hand, there may be several correct ways to fix it:

void foo(int a, int b,
         int c, int d)
{
    int bar =
        a + b - c * d;
}

void foo(int a,
         int b,
         int c,
         int d)
{
    int bar = a + b
            - c * d;
}

With canon enforcers, there’s one way to format code. Anything different is basically incorrect, and ends up being formatted back to the One True Style.

Now some of you may say that limiting lines to 25 columns is a tad restrictive. How about raising that limit to 80? With that, the first version I showed above becomes correct. It’s a win!

Well, it depends. I can feel like 80 columns is a bit large, and really, most of the time a limit of 25 is okay. We have to have a hard limit, but it’s nice to have a soft (unenforced) lower limit as well. Besides, what if variables are related in some logical way? In such a case, the most readable code might look like this:

void foo(int a1, int a2,
         int b1, int b2)
{
    int bar = (a1 + a2)
            - (b1 * b2);
}

Enter the canon enforcer. With those, if I chose to set the limit at 80 column, they will prevent unneeded line breaks. But this completely breaks the spirit of a soft lower limit!! And I can kiss semantic groupings goodbye.

In a real project I’m working on, the architects wrote in the code style that we ought to observe an 80 column soft limit. But the formatting tool they gave us is configured company wide to 120 columns. And because clang-format is a canon enforcer, it means I cannot break lines that would take between 80 and 120 characters.

A similar problem occurs for function calls. Either the whole call fits in less than 120 columns, and it has to be a single line, or it does not, and the only accepted style is one argument per line. So instead of:

do_stuff_with_buffers(buffer1, buffer1_size,
                      buffer2, buffer2_size,
                      buffer3, buffer3_size);

I was forced into this less readable:

do_stuff_with_buffers(buffer1,
                      buffer1_size,
                      buffer2,
                      buffer2_size,
                      buffer3, buffer3_size);

Pretty infuriating.

Now if you don’t care about style, canon enforcers are great: they prevent your carelessness from polluting the code base too much. I however do care. and when the tool forces me into something that is clearly less readable than what I’m trying to achieve, within the confines of the official code guidelines, I die a little inside.

Having some rules is good. But don’t overdo it.

I don’t know of a good C++ code formatter, but clang-format is not one. It is a thing I don’t like about C++.

Good for you, clearly other people disagree with you, so it may be worth asking whether your practical experience is different from theirs. One of the most frustrating parts of many projects I’ve been involved with over the laws was ensuring consistent formatting. clang-format was the first, and in my experience only, effective for all c++. The best anyone was other wise able to do is style error check scripts, which were both necessary and also objectively annoying.

Myth 1: Any coding standard is as good as another.

There is such a thing as practicality in coding standards. Before even contemplating controversial topics – aesthetics, it’s not hard to think of aspects of code formatting that contribute to write amplification – how big a change becomes in the resulting diff – that should be uncontroversial. Let’s get the basics right:

Most of what you list here I would consider a bad style, because style has significant subjective elements. Other aspects of the coding style are significantly impacted by the nature of the apis in the project.

Furthermore, clang-format supports a number of standard (from the largest clang using projects) style guidelines, but also lets you come up with you own arbitrary clunky rules.

Regardless it does not appear people say any is equivalently good, but that people have different subjective opinions as to what is “good”. You may disagree with me, but that simple fact that I and others in the replies disagree with you should hammer home that you are incorrect in your belief that there is a single “objectively” superior format.

Myth 2: The most important thing is to have a coding standard and enforce it. I remember a time before clang-format: I would say that professional developers did at least as good of a job as clang-format to begin with. In fact, in some ways better than any autoformatter could ever come up with, because the human knows best, such as which arguments are associated.

Hahahhaha, no, no large scale project operated like that. They had manual, and eventually heavily scripted, style checks on all commits.

For large projects with significant numbers of contributors, having a consistent style is incredibly useful, as in the real world large project will have different people working in different areas, and moving around between different areas. Having wildly diverging style from one area to the next makes it much more challenging that it needs to be for a person to hop from one area to another.

It is possible that you have simply not worked in large scale software development and engineering projects so have experienced the value.

Freedom of expression! This openness to creativity made the conventions fluid, so that better ideas had a foothold.

This is nonsense. The freedom of expression comes from the code you write, not your formatting. Using random formatting rules serves only to make it difficult for other developers to read and maintain your code.

If the purpose of automatic formatting is to avoid style disputes in code review

No the purpose of automatic formatting is so that you don’t have to go through manually correcting all the formatting errors yourself.

it doesn’t work It objectively does. When I can use clang-format I don’t have to go through manually looking for formatting errors

because too few people know the importance it gives to trailing comma – I have to nag people about it.

wtf are you talking about?

Myth 3: It is possible to configure clang-format to a pythonic/rustic style.

No comment as I have no idea what you’re talking about

Myth 4: It is always convenient for everyone to run the formatter.

It doesn’t actually matter how convenient it is, because I don’t necessarily approve of what it does to my code – I can’t run the formatter before I have committed my changes anyway. Then, I rewrite my code to comply if needed be. If revising one’s commit stack isn’t hard enough as it is, doing it with style changes into the mix is the worst.

It is a hell of a lot more convenient that multiple manual passes to find and correct style issues. For projects I work with where clang-format isn’t an option the patch review system automatically runs style checkers to tell you where your errors are, and you have to fix them, or you manually run the script before posting to correct it then.

Not sure what you think your saving by doing it manually, I remember the annoyance of patch cycles when there were format errors.

2. Properties of a good formatter

Sensible by default, or a sensible configuration (after the criteria above) must exist in its configuration space.

clang-format has a very sensible set of default configurations: the formatting rules of a collection of the largest C++ projects in development: LLVM, GNU, Google, Chromium, Microsoft, Mozilla, WebKit

Those are reasonable defaults. If you want something different clang-format allows you to control near as I can tell every aspect, you can even derive from one of the above.

The formatter’s job is not to take this freedom of expression away. Its job is to satisfy a disjoint set of requirements. > Therefore, it must allow more than one way to lay out the same code.

I do not understand wtf you are talking about with this “freedom of expression” bullshit. The reason projects have style rules is specifically to halt the problems caused by randomized code styling. clang-format does a far better job than any of the preceding tools, most of which were at best scripts that used regexes to find and report errors.

Humanly predictable. 3. So what’s wrong with clang-format in particular? All the above. If clang-format behaved like a python formatter or like rustfmt, you wouldn’t be reading this. Though I’m no fan of automatic formatting in general, other languages have it better.

It sounds like you simply have not worked in actual large scale software development based on how much value you think you are adding by using you own randomized coding style, where every experienced developer here will almost certainly tell you that pretty much any consistent style is superior to inconsistency. Even LLVM’s wretched style guidelines are better than variable.

Myth 1: Any coding standard is as good as another.

This is an odd strawman to start with. I’ve very rarely heard people argue this. More generally, the ordering from best to worst is:

1. A good style that you’re familiar with.
2. A bad style that you’re familiar with.
3. A good style that you’re unfamiliar with.
4. A bad style that you’re unfamiliar with.
5. No consistent style.

Without clang-format, you generally end up in category 5. Some projects have style rules that they manually enforce, but they’re generally ambiguous (the amount of my life I’ve wasted with people bikeshedding about different interpretations of FreeBSD’s style(9) is huge). LLVM has an objectively bad style (there are a number of rules in it that make it easy to introduce specific bug categories) but it’s now consistently applied by clang-format and, now that I’m familiar with it, I know the things I need to pay more attention to in code reviews. This is better than no style and is better than a good style that I’m not familiar with and need to train my eyes to follow.