The Educational Aspect of Static Analysis

Very often new programmers who join our projects ask us whether we have auto-formatting instruments to make Java code look exactly the way Qulice expects. (Qulice is the static analyzer we use.) I always reply that having such an automated code polisher would only be harmful and wouldn't help the project and its members improve and grow. Here is why I think so.

Blind Fury (1989) by Phillip Noyce

Static analysis, the way we do it in combination with read-only master branch, is a fully automated uncompromising review of your pull request, mostly intended to spot code formatting mistakes. Say we want Java code in our entire repository to look like this:

However, you refactor it as part of a bigger task, and submit a pull request like this:

classDoc{privateFilef;publicvoidremove(){if(f.exists())f.delete();}}

For some of you this may not seem like a big difference, since both code snippets compile without issues and work exactly the same way. However, for us, the repository maintainers, it is a big deal. We do want our classes to always be final, we do want them to be immutable (so all attributes should also be final), we want to prefix all attribute references with this., and we want the code to be formatted the same way, since we believe that the uniformity of the code seriously increases its maintainability.

Of course, we could create a tool which you could then use to re-format the code, to make it look the way we want. But in that case you would never learn what the project wants from you and why.

You will not know the reasoning behind our rules. You will never think about them. You will not really care about them. But they are not only about the formatting of spaces and brackets. There are over 900 of them in Qulice and some of them were designed especially for the object-oriented philosophy we are preaching.

Thus, simply put, we don't want you to go through the static analysis phase easily. We want you to suffer in order to learn.