Smart Tech for a better Web
In late summer I was contacted by Radu from Intooitus. He heard about my work for Apache Struts 2 and generously offered a license for their product, inCode. I was first sceptic. Maybe it's just me but I have never seen a code analysis tool which I really loved. Usually I am asked to blog about a product when I get a free license, but Radu said it's not necessary.
I am blogging today, because I was wrong with my scepticism. inCode is really a great tool. When I unpacked it I realized it's build upon the Eclipse framework. While I don't like the Eclipse code editor anymore, I always loved the look & feel. inCode is great looking and if you have used Eclipse in the past, you'll be happy about the applications interface.
I really have not had a clue about inCode before I started, but after I selected the folder which contains Struts 2 I could navigate through the analysis without any problems. inCode identified 15 God classes, 146 Data classes and a lot more problems. I didn't know what a "Tradition Breaker" was, but I was taught with a simple click. inCode doesn't expect you to be an Über-Architect (which I am not). It showed me the class source code and an explanation what's wrong. The explanation contains a few more links, which can highlighted problematic methods. The whole application is easy to understand and nice to work with. It's also nice inCode suggests what I could improve. The tool doesn't only improve my code. It helps me to develop myself too and to think twice on my decisions.
When I compared the code with the classes it mentions I could only agree. In most cases inCode reported classes which were horrible to read and hard to understand. There is something to fix in Struts, but lucky me inCode ranked the most critical issues after severity. At least now I know where to start.
One thing worth mentioning it is the "polymetric software visualization". It was the only thing I didn't find intuitive yet. But I decided to learn a bit more about it. If you would like to learn more, you can check out Intooitus PDF on the topic.
What you see in the image above is the visualization of Struts 2. The Blocks on the top right are my packages and classes. For this screenshot I enabled the "complexity" view and so more red you see, so more complex is the class. When I hover over it I can see the class name and get some additional tools via the context menu.
I can already identify a lot from this view. I see, the org.apache.struts packages are bigger than the com.opensymphony.xwork packages. They look even more complex. I can estimate the size and complexity of each and every plugin. This alone is already great. Now I was able to activate some kind of search window and I typed "Interceptor". inCode enclosed every Struts Interceptor with green color. That way I can easily identify which packages contain Interceptors and which not. Furthermore I can identify the most complex Interceptors and double check if they need a refactoring or not. In the same way there is a "Class Map" available, which visualizes a class and not the whole package structure.
I emailed to Radu Marinescu again about the different views. Radu is part of the Intooitus core team and was so kind to reach out for me with my license. Here is what he responded:
Let me give you an example: for "God Class" the main issue is the fact that the class is using data (class data-members) from external classes (directly or via getters/setters). Now, for this issue of encapsulation breaking the "understanding toolbox" gives you three possible points of view to reason about it:
a "structural" view (in form of a double containment tree) - in which you see which method is using which external data, and which other methods, from other classes are using the same data. This helps me answer the question: (how easy) can I move data-members closer to the places where they are used?
a code view - in which external data accesses are highlighted in code. This help me answer another question: what is the code contexts in which I use these data? does is really make sense to use that external data there? is this data access thing an isolated problem or is it spread over the entire class? (you can see this by the distribution of markers on the right-side ruler)
a polymetric visualization (the Class Map, with the Encapsulation perspective) - in which both data members and methods are depicted visually. This allows me to answer other questions: am I relying on those external classes only for data access? how strong is the data usage (by the colour intensity)? how large are the methods (by rectangle size) that use the data? are the classes that expose data from classes that are "close" to my class, i.e. from the same and/or sub-packages (by the border color)?
In brief: the various exploration tools are complementary in the questions for which they can provide answers... this makes you (the developer) very much in control, because you can quickly find answers to your questions (on how to improve the code) by combining the information from the various tools.
(email from Radu Marinescu)
Of course I know Radu and his company wants to make business and hey, I would get back to a blogger testing my tool as quickly as he did. I would like to note I always felt the contact with Intooitus was very friendly and honest. Radu invests a lot of time in responding to user emails. If they treat their customers like they treated me, it's recommended. For some reason I have no doubt about them.
In general inCode was a great experience and I am eager to work a lot more with it. The tool has grown quickly into my workflow and gave me a lot of inspiration and insight what things I want to check when working on Struts 3. inCode is available at a fair price starting at 79€. If that's not enough and you need more help for a huge environment, you may check out inCodes big brother inFusion.
UPDATE: The company unfortunately does not exist anymore.