{"id":18735,"date":"2019-05-27T10:43:13","date_gmt":"2019-05-27T08:43:13","guid":{"rendered":"https:\/\/blog.trifork.com\/?p=18735"},"modified":"2019-05-27T10:43:13","modified_gmt":"2019-05-27T08:43:13","slug":"verifying-coding-standards-using-static-code-analysis-techniques","status":"publish","type":"post","link":"https:\/\/trifork.nl\/blog\/verifying-coding-standards-using-static-code-analysis-techniques\/","title":{"rendered":"Verifying Coding Standards Using Static Code Analysis Techniques"},"content":{"rendered":"\n
\"\"<\/figure><\/div>\n\n\n\n

In a previous blog<\/a> we described how we used JUnit and Reflection to verify correct implementation of coding standards addressing Axon Upcaster consistency. We concluded that, although possible, it felt a bit like a hack because we had to change modifiers of Java variables defined as \u201cprivate static final\u201d resulting in Java security manager warnings. We also promised to get back to the subject, this time using static code analysis technology as found in e.g. SonarQube<\/a>.
<\/p>\n\n\n\n

Before we present our solution we recap the case at hand and we will of course close with a comparison and draw some conclusions.
<\/p>\n\n\n\n

Source code consistency<\/strong><\/h1>\n\n\n\n

The system we were building in my project is using the Axon framework (Axon Framework)<\/a> . In Axon all events in the system end up in an event store to be used for event sourcing later. We for example defined \u201cPersons\u201d and \u201cOrganisations\u201d where Persons work for Organisations. During development such entities evolve<\/em>, for example, they get a new property. Events such as \u201cOrganisationUpdated\u201d therefore become versioned<\/em>. When new versions, in Axon terms revisions<\/em>, contain new properties we have older events in our event store without those properties. This is a problem if the new property is mandatory. In Axon terminology they need to be upcasted<\/em> by Java classes called Upcasters to allow for event replaying. Over time there will be several upcasters taking an event first from revision 0 to revision 1, then from 1 to 2 and so on until we reach the current one.
<\/p>\n\n\n\n

In our project we introduced a generic way of managing upcasters and we introduced a coding standard for it as follows. We have an event in Kotlin defining the current revision like this:
<\/p>\n\n\n

\n@Revision(\"4\")\ndata class OrganisationUpdatedEvent(val id: String, val\n name: String, \u2026\n<\/pre><\/div>\n\n\n
Next we have a series of upcasters where the name immediately tells what it does, like:
<\/p>\n\n\n
\nOrganisationUpdatedEventUpcasterNullTo1.java\n<\/pre><\/div>\n\n\n
And
<\/p>\n\n\n
\nOrganisationUpdatedEventUpcaster1To2.java \n<\/pre><\/div>\n\n\n
Next, each of these upcasters contains code like this:
<\/p>\n\n\n
\nprivate static final SimpleSerializedType INPUT = new\n\t  SimpleSerializedType(\n\t\tOrganisationUpdatedEvent.class.getName(), \"1\");\nprivate static final SimpleSerializedType OUTPUT = new\n\t  SimpleSerializedType(\n\t\tOrganisationUpdatedEvent.class.getName(), \"2\");\n\n<\/pre><\/div>\n\n\n
Upcasters use this information to \u201crecognize\u201d if a particular revision of an event can be upcasted. Finally upcasters are Spring Components requiring a particular ordering, so we have code like this:
<\/p>\n\n\n
\n@Component\n@Order(1)\npublic class OrganisationUpdatedEventUpcaster1To2\n<\/pre><\/div>\n\n\n
We need this ordering because Axon runs all events through a list of all upcasters it knows about at event replay time. Axon does not impose anything in terms of ordering on that list, but we want to apply upcaster \u201c\u2026NullTo1\u201d before \u201c\u20261To2\u201d etc. Managing Axon upcasters over time will be another blog post, as there are a couple of alternative implementations all with different pros and cons. 
<\/p>\n\n\n\n
Let us get back to our current subject. To summarize, in our coding standard we have:<\/p>\n\n\n\n