Hi, brian m. carlson wrote: >> On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote: >>> We may have different opinions on what is readable/beautiful code. >>> If we were to follow a mutual agreed style that is produced by a tool, >>> we could use clean/smudge filters with different settings each. I think this is a long way away --- long enough away that by the time such a change could be a serious possibility, a lot may have changed and the project is likely to know a lot more. In other words, I don't see speculating about that future as being likely to produce useful results today. It would be a different story if we were writing a new codebase from scratch. In that case, I would be all for the gofmt approach. :) > On Wed, Aug 09, 2017 at 07:19:00PM -0400, Jeff King wrote: >> I'm less worried about a difference of opinion between humans. My >> concern is that there are cases that the tool's formatting makes _worse_ >> than what any human would write. And either we accept ugly code because >> the tool sucks, or we spend a bunch of time fighting with the tool to >> try to make its output look good. > > This has been my issue with clang-format in the past. I have an SHA-256 > implementation with an array of 64 32-bit hex integers. These fit six > to a line, but for neatness and consistency reasons, I'd like them four > to a line (4 divides 64, but 6 does not). Last I checked, clang-format > didn't allow me that option: it reordered them because it could fit six > on a line. This is not the only issue I discovered, just the most > memorable. In case it comes up again for you in a project that has adopted the gofmt approach: you can signify that your line breaks are intentional by putting line comments at the end of each line and clang-format will respect them. The clang-format documentation also mentions[1] that you can do /* clang-format off */ const double kIdentityMatrix[] = { 1, 0, 0, 0, 1, 0, 0, 0, 1, }; /* clang-format on */ Thanks, Jonathan [1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code