Explore the Most Common CodeMRI® Reports

CodeMRI® Sys Admin Training Videos:

Exploring the Most Common CodeMRI® Reports

Having run our jobs produce reports and produce THIP. We now have a directory in our vault under reports, under the Axis project, under the Axis2 system in the language of Java, we have the five reports from produce reports, and we have the technical health improvement plan from produce THIP. So now we can take a quick look at a couple of these and point out some of the more interesting things.

So if we look at the main report CodeMRI-, and then system name, we can see here on the summary page that it provides a summary about the system, the language that was scanned, the number of code files that it found, the number of lines of code, the average size of a file, and lines of code. And then, it provides some technical health summary information on design quality and code quality.

The design quality information is in the form of file cores. File cores are circular dependency relationships among a set of files. Code quality is expressed as McCabe complexity, McCabe complexity. The McCabe score is based on the number of unique executable paths through a file. So, if we look at design quality, in cores, we have two critical cores with over a hundred thousand lines of code, and then two emerging cores made up of over 40,000 lines of code.

A critical core is a set of files that form a circular relationship of dependencies. And to make it critical, it's over 150 files. An emerging core is between 30 and 150 files to make up that core for McCabe complexity. Um, files and low complexity are between 0 and 10. Medium complexity is from 11 to 20, and high complexity is anything over 20, and we can see here that we have five files that are in high complexity.

We have 273 in medium, and then the rest are in low complexity. This is all summary information and if you want detailed information here at the bottom, you can click on the file list tab and then we'll show you every file that was scanned. And it'll give you information on every single file. We can see the language, the extension, we can see. Let's scroll over here. So we can scroll through here, and we can see cyclic group size. So, this file isn't a cyclic group made up of 177. We can see fan in, fan out visibility, fan in visibility, fan out. Those numbers are how many other files are dependent on this file and how many other files this file depends upon.

And if we scroll over some more, we can see cyclomatic score. This is the McCabe score, as well as the category that it falls into. We can see lines of code and source lines of code. We can see comment ratio, which we haven't talked about yet. Comment ratio is the ratio of the number of lines of code that are comment versus the number of lines of code that are not comments.

So, for instance, this file here is a 70% ratio. That means for every 10 lines of code, there's seven lines of comments. Gives you an idea of how well a file is documented. If we scroll over some more, we have component information. CodeMRI® has the ability to define files as belonging to a component, and we'll discuss more on that in a few minutes.

We see percent of duplicate code. This is the percent of code that exists that is duplicated, uh, segments of code that are duplicated in more than one place, and this is the percent of the codebase that is considered to be duplicate. We'll have more on that later. We also have the ability to tag a file as being either a third-party file-generated code or a test file.

Uh, we'll talk about how to do that. That's also a common command that's useful if you're going through this and trying to develop metrics. A lot of the time you don't want to include a test file or a third-party files in any of those metrics. Another file we're gonna look at is the code duplication file.

We saw that in the made main code CodeMRI® file where it describes the percent of duplicate code in a particular file. The code duplication report is a roadmap to where all the duplication lives, and if we look in this file on the main tab, it shows. The percent of duplication in the system, and then the percent of removable duplication.

Now, of course, when you have duplication, say you have four segments of code that are identical across your code base, well, you're gonna have to keep one of those. So, percent duplication would be all four sets. Removable duplication would be three sets, since you have to keep one, we can look at the roadmap here, which is duplication instances.

Now, these are all grouped into sets as a piece of duplicate code is not necessarily contained within one file. Now, if we sort this, we can take a better look at this. Here you can see I've sorted on the duplication instance id. These are grouped by files that all share the same piece of duplicate code. And we can see here, uh, there's two files in duplication.

Instance ID two, meaning both of these files both have an identical segment of code. And if you look at the line here, it'll tell. If you go into that file, if you look starting online 103 and ending online 465, and then you go to the next file and start at line 101 and end on 463, the code in those two segments will match, and you're able to do some refactoring to uh, shrink your codebase.

And if we scroll down a little bit here, we'll see In duplication instance ID 51, there are a number of files that all share duplicate code. So doing some refactoring here would can shrink your code base considerably if it's possible. Another file that's full of good data is the detailed worksheet inside of the detailed worksheet. CodeMRI® discovers all the references that are made within the system. They're labeled from component down to file, down to entity. You know, as components are all empty. That's because no components were defined for this system. But if we look here, we can see that from this file and this entity within this file, starting at this line, is making a reference to something in this file.

Which is the entity. It also tells us whether this relationship is expected and whether this relationship is circular or not. Expected is something that would be filled in had components been defined and in relationships between the components defined, and this would indicate whether that relationship is breaking any of those defined rules.

And lastly, we can take a look at the Technical Health Improvement Plan. The Technical Health Improvement Plan lays out a roadmap for breaking up file cores. Here we have two plans, one for a core of 177 files, and then there's another plan for a core of 159 files. Both of these are critical cores. It lays out steps, and it shows that as follow the steps, how much of a reduction you can expect in your core. And the steps are laid out here, and it'll show you. These will all be under step one, and it'll say from this file and from this entity. And then, if you go to this file and this entity and find a way to resolve that dependency, and as you go down the line, you will start breaking up that core.

Okay, that's just a brief overview of the reports. There's a couple of others in here. These are chock-full of good information. Feel free to browse these as you can.