Note code formatter explicitly under tools goal?

[jonmeow]

https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#language-tools-and-ecosystem doesn't note a code formatter as a goal. This maybe slipped past us as worth noting explicitly. Need to see what others think.

[davidzchen]

+1 I also think that we should establish a standardized, consistent coding style with recommended best practices and provide a code formatter, similar to other modern languages such as Go and Rust. I think that ideally, the compiler tool chain should also include some style-related static analysis checks, similar to that of Go. For instance, Go would fail the build if there is a module being imported but is not used in the code.

I think this would mitigate another one of the C++ ecosystem's existing issues where there are wildly different coding styles and code organization conventions being used across different codebases.

[nigeltao]

Y'all should absolutely have a code formatter.

Bonus points if, like gofmt, the command line tool can do basic "rename all foo variable/function names to bar" edits that's smarter than blasting it with /usr/bin/sed.

[nigeltao]

Also bear in mind that The Hardest Program I’ve Ever Written discusses dartfmt (and Bob Nystrom is an excellent programmer, of What Color is Your Function? and Crafting Interpreters fame). Formatting Dart is so hard because:

If every statement fit within the column limit of the page, yup. It’s a piece of cake. (I think that’s what gofmt does.) But our formatter also keeps your code within the line length limit. That means adding line breaks (or “splits” as the formatter calls them), and determining the best place to add those is famously hard.

I strongly recommend not having an artificial column limit (e.g. at 80 chars) in whatever style carbonfmt chooses as canonical, because it dramatically simplifies the formatting problem.

[nigeltao]

Also, make it fast. I work on the Chromium C++ project and there has been multiple times when I've wondered "why is my commit / upload hook taking so long" and the answer turned out to be "it's running clang-format".

Quoting myself from Dumbindent: When 93% of the Time was Spent in Clang-Format

The Wuffs compiler outputs C code. When compiling its standard library, over 93% of the time (2.680 out of 2.855 seconds) was spent formatting that C code with clang-format. dumbindent is a new command-line tool (and Go package) that formats C code. Its output is not as ‘pretty’, but it can be over 80 times faster than clang-format (0.008 versus 0.668 seconds to format 12k lines of C code).

As noted in the blog post, clang-format will actually crash (out of memory, after 25 seconds) if you try to feed it SQLite's source code. Obviously, carbonfmt should be more robust than that.

Admittedly, part of why clang-format is so complicated (and hence takes so long / uses so much memory) is that the C/C++ preprocessor exists, and can insert itself in the middle of multi-line statements. Don't have a preprocessor in Carbon. But you already knew that.

[nigeltao]

(Yes, I have an unusually large interest in code formatters and I have opinions) :smile: