Unveiling the Power of Server-Side Code Inspections
People often ask us: “How do you know when the product is ready for release”? For TeamCity one of the important conditions was that it had to be able to run off-line inspections on the entire IntelliJ IDEA 6.0 source code.
This was quite a challenging task: IntelliJ IDEA includes more than 30.000 various classes. Nevertheless, TeamCity had produced the complete analysis report only after 10 hours of digging through this vast amount of code.
Of course, there were various mistakes and disrepances in the sources. Not mentioning trivial things like public methods not ever used anywhere, we discovered really hard-to-catch errors like this:
As you can see, the inspection says that myFileToUrl does not have to be a field and can be converted to a local variable, because it’s only used in one method and queried only after it is assigned (so, there is no need to save its value between the calls to the method).
At first glance it looks harmless to go on with the conversion, but after taking a closer look we realized that the author made an effort to cache the result of a time-consuming calculation (the “for†loop), but stopped halfway.
We added the guard condition and the inspection promptly went away:
The original intention is now implemented correctly : the HashMap is created only at the first method invocation. The caching is now working, and IntelliJ IDEA became slightly faster than before.
In fact, this particular problem could have been easily detected by the IntelliJ IDEA on-the-fly error highlighting feature. All we needed to do was to open this file in the editor and look through the code. The problem is that in real life, this might not have happened for weeks of even months.
The server-side inspections are important and powerful because they give you the complete list of suspicious code fragments, including the ones which you would never stop at while just browsing the code in the editor.
Subscribe to IntelliJ IDEA Blog updates
