Code Meterics
-
Having just discovered code metric in VS2013 I naturally pushed the button got a bunch of interesting numbers which MS describes but I was wondering what a good maintainability index should be, I have 80 over 11k lines of code.
Never underestimate the power of human stupidity RAH
-
Having just discovered code metric in VS2013 I naturally pushed the button got a bunch of interesting numbers which MS describes but I was wondering what a good maintainability index should be, I have 80 over 11k lines of code.
Never underestimate the power of human stupidity RAH
One thing that code metrics doesn't really cope with is the complexity of the system. The design can only be built to solve the requirements (with a bit of future proofing if time allows), like most statistics they can give you a feel of what is going on but sometimes you have to trust your experience
-
Having just discovered code metric in VS2013 I naturally pushed the button got a bunch of interesting numbers which MS describes but I was wondering what a good maintainability index should be, I have 80 over 11k lines of code.
Never underestimate the power of human stupidity RAH
By itself, a high level Maintainability Index doesn't actually add much value. You need to drill down and look in more depth - see what the maintainability is as you drill into the project, and don't forget to pay attention to the cyclomatic complexity. If this 80 was reflected all the way down, it would indicate that there weren't too many major issues, but your cycolmatic complexity is probably going to be high. According to Microsoft[^], they calculate the cmoplexity based on this formula:
Maintainability Index = Max(0,(171 - 5.2 * log(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * log(Lines of Code))*100 / 171)
-
By itself, a high level Maintainability Index doesn't actually add much value. You need to drill down and look in more depth - see what the maintainability is as you drill into the project, and don't forget to pay attention to the cyclomatic complexity. If this 80 was reflected all the way down, it would indicate that there weren't too many major issues, but your cycolmatic complexity is probably going to be high. According to Microsoft[^], they calculate the cmoplexity based on this formula:
Maintainability Index = Max(0,(171 - 5.2 * log(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * log(Lines of Code))*100 / 171)
I was curious more than desperately looking for something to do, like testing frameworks we simply do not have the time and resources to spend on those sort of niceties. There is never enough time to build the stuff they want, a few years ago I started calling our apps POCs hoping to get a second bite at them, never happened, we have over 20 POCs in production.
Never underestimate the power of human stupidity RAH
-
I was curious more than desperately looking for something to do, like testing frameworks we simply do not have the time and resources to spend on those sort of niceties. There is never enough time to build the stuff they want, a few years ago I started calling our apps POCs hoping to get a second bite at them, never happened, we have over 20 POCs in production.
Never underestimate the power of human stupidity RAH
I always find it interesting the way that companies are willing to accept an accretion of technical debt. The concept that there's no time for testing or working to a loosely coupled, easily extensible application makes me want to sit back and watch as the whole edifice comes crashing around them once they have to significant upgrades that just don't fit into this untestable, tightly coupled monstrosity that they have pressured people into building. The analogy that I like to work with is building a house. If you built a plastic house shell and decided two years down the line that you wanted to extend it - say by extending the base level out 30 foot, you will expand a heck of a lot of effort and what you would end up with would be significantly weakened at the join points (this is assuming that you could do it). Now, if you build your house out of bricks, while it may take you longer to join them together initially, if you want to upgrade the house later on it's significantly less work and as long as the job is done properly, the superstructure is not weakened in any way.
-
I always find it interesting the way that companies are willing to accept an accretion of technical debt. The concept that there's no time for testing or working to a loosely coupled, easily extensible application makes me want to sit back and watch as the whole edifice comes crashing around them once they have to significant upgrades that just don't fit into this untestable, tightly coupled monstrosity that they have pressured people into building. The analogy that I like to work with is building a house. If you built a plastic house shell and decided two years down the line that you wanted to extend it - say by extending the base level out 30 foot, you will expand a heck of a lot of effort and what you would end up with would be significantly weakened at the join points (this is assuming that you could do it). Now, if you build your house out of bricks, while it may take you longer to join them together initially, if you want to upgrade the house later on it's significantly less work and as long as the job is done properly, the superstructure is not weakened in any way.
As I work for an organisation that outsourced it's entire IT, development and support to IBM in the 90's I feel bloody lucky to get the limited resources we have. We are treated as pariahs by IBM and obstructed by policy set for pig iron systems. Other that ours and 2 other DEPARTMENTAL teams they have absolutely no IP, everything comes from a vendor, basically they drop their pants, bend over and the vendors fuck them. While the apps taken as a whole maybe monstrous 11k lines of code is probably about average, all are built on the same framework and all conform to our internal standards so they get supported and extended, not a 30' room but more like a dunny or 2.
Never underestimate the power of human stupidity RAH
-
Having just discovered code metric in VS2013 I naturally pushed the button got a bunch of interesting numbers which MS describes but I was wondering what a good maintainability index should be, I have 80 over 11k lines of code.
Never underestimate the power of human stupidity RAH
Maintenance Complexity[^] I don't know how similar CodeRush's calculation of maintenance complexity is to VS's but I would imagine they're similar. Scroll about 2/3 down to see the MC table. So, approximately no more than 200 to be "relatively easy to maintain." I tend to pay more attention to cyclomatic complexity. I like to get below 10. But sometimes you can be below 10 here while being over 300 in MC. I have one such method in my current section of code. My aim is to keep both measures low in general (in cases where I have control) but if the odd case is higher than the ideal figures then evaluate it on its merits.
Kevin