Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This PR is an initial attempt to build some consensus around a consistent, automated code style for the K Frontend's Java code. Other parts of K already do this for other languages, and so I think there's a pretty clear precedent that we should want to set something similar up for our largest, oldest codebase: * The LLVM backend's C++ code is formatted with [`clang-format`](https://github.com/runtimeverification/llvm-backend/blob/master/.clang-format) * The Haskell backend (and booster)'s Haskell code is formatted with [Fourmolu](https://github.com/runtimeverification/hs-backend-booster/blob/main/fourmolu.yaml) * Pyk's Python code is formatted with [Black](https://github.com/runtimeverification/pyk/blob/41706ef5081585a4c71f7fccb4dea2d7a3796421/Makefile#L88-L89) At a high level, the notional benefits of doing this are: * Improved readability of code * More focused PR review; no consideration needs to be given to formatting when reading and reviewing code * Eliminates "diff noise" from unrelated formatting changes * Consistency across the whole codebase; there are nearly 100 unique contributors to K which means that small variations in style have been accrued over time I have done some research into available auto-formatters for Java, focusing on the following points: 1. Is the style agreeable to developers, and do we as a team feel happy with the results it produces? 2. Can the style be applied locally using our existing tools[^1]? 3. Can the style be enforced in CI using our existing Github Actions infrastructure? 4. Is there a community consensus around using this style in practice? Beginning with (4) the standout contender for a "standardised" tool that's used by lots of Java developers in practice is Google's `google-java-format` tool, which is designed to apply the [Google Java Style](https://google.github.io/styleguide/javaguide.html) automatically. This PR focuses on using this tool and evaluating its tradeoffs; if we later decide it's totally unworkable then we can revisit this evaluation with a different tool. My summary of the pros and cons of this format are: #### Pros * Implemented and maintained by a large company who rely on it for their own tooling. * Includes support for new language features and syntax. * It is unlikely that Google will stop using this tool on their Java code, and so the chances that it ends up bit-rotting into uselessness are very small. * Active secondary ecosystem for IDE and CI tooling. * Official IntelliJ plugin * Third-party, actively maintained Maven integration * Third-party, actively maintained Github action * **Personally speaking**, I like the style that's been applied; a skim through the diff suggests that some of the expressions I've found hardest to parse in the frontend are now a bit clearer * Easy enough to get working locally; the only real issue I had was that I seemingly hadn't updated IntelliJ in two years and the JDK version it has internally was too old. * Works well in CI; this PR adds an action to the test workflow that checks formatting. #### Cons * Not configurable beyond 2/4 space indentation; this is by design on Google's part[^2]. * One big diff will end up getting applied to the whole project[^3]. * Others may not prefer the style used. I hope that this is a fair summary of the tradeoffs of doing this kind of tooling update; I'd like to get opinions from everyone who works on this code to make sure that we're all as happy as possible with what we end up doing. Things to think about in particular: * Do you like the code style, from skimming the diff? * Does the "format locally with IntelliJ, check + enforce in CI" workflow work for you, or would you rather have CI make commits to your branch so that you don't have to worry about formatting[^4]? * Are there other tools you're aware of to do the same job? [^1]: By this I really just mean IntelliJ; I'm not aware of anyone using different tools to develop the K Frontend. If you're using some other setup then please let me know! [^2]: This is also the situation we have with Black for Python, however, and that works fine! [^3]: Though this is true for _any_ formatter, and we probably just need to accept this pain as a once-off cost of doing business. [^4]: The former is how we do automatic formatting for the other projects, so I am treating it as the default option here.
- Loading branch information