3 ms·
But LLVM's C++ formatter and autopep8 are superior in functionality to gofmt for their respective languages. I was under the impression that some of the syntax
by ansible 11y ago
But LLVM's C++ formatter and autopep8 are superior in functionality to gofmt for their respective languages.
I was under the impression that some of the syntax for C++ and / or C is a bit ambiguous, which makes it difficult to parse correctly, and to make source code transformations that will absolutely, positively not change the semantics of the code.
At any rate, getting more or less the entire community onboard with using one particular code formatter is the really hard part. I'd say it is impossible to do with existing languages. I don't see how the majority of in-production C++ code, or Python code will ever be formatted in one fixed style.
So even if superior formatters exist in those languages, it doesn't matter, because the majority of code I will encounter out in the wild (open source or not) will not be formatted in with a single convention.
If there is one lasting legacy from the creation of golang, it is hope that for all new languages, their communities will adopt a single code formatting convention. I hope that everyone, whether or not they like golang itself, sees how important that is moving forward.
- coldtea 11y ago>I was under the impression that some of the syntax for C++ and / or C is a bit ambiguous, which makes it difficult to parse correctly, and to make source code transformations that will absolutely, positively not change the semantics of the code. That's for naive parsing of C++, like some do for syntax highlighting etc -- not for LLVM's C++ formatter, which uses the AST of the fully blown C++ compiler et al. If that parser didn't get everything right, then LLVM's C++ output will also be borked, not just the formatter.