Core Java

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:

final class Doc {
  private final File file;
  public void remove() {
    if (this.file.exists()) {
      this.file.delete();
    }
  }
}

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

class Doc {
  private File f;
  public void remove()
  {
    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.

Published on Java Code Geeks with permission by Yegor Bugayenko, partner at our JCG program. See the original article here: The Educational Aspect of Static Analysis

Opinions expressed by Java Code Geeks contributors are their own.

Yegor Bugayenko

Yegor Bugayenko is an Oracle certified Java architect, CEO of Zerocracy, author of Elegant Objects book series about object-oriented programing, lead architect and founder of Cactoos, Takes, Rultor and Jcabi, and a big fan of test automation.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button