Archives
- ► 2012 (8)
- ► 2011 (157)
- ► 2010 (174)
- ► 2009 (12)
Which topics would you like us to cover more?
Latest comments
- How to reset you Kindle
3, eve...
Thanks for this article and the related "Inside th...
By H K - How to reset you Kindle
3, eve...
How do you drain power on the board? I dont have r...
By Grace - How to reset you Kindle
3, eve...
You're welcome!
By Bas - How to reset you Kindle
3, eve...
Thanks man....removing the battery worked like a c...
By DaveMan - nHapi
example
Hi Slypete, Thank you for your comment. This way w...
By Bas - nHapi
example
Hello, Employing .Net dynamics, one can implement ...
By slypete - Implementing MLLP in C#
Hi Mayura, I'm not sure I understand your question...
By Bas - Implementing MLLP in C#
I have used SSL stream to secure the MLLP transact...
By Mayura
Latest tweets
Architecture, security and coding Measuring code
quality| Measuring code quality |
| Written by Division by Zero |
| Tuesday, 11 May 2010 21:54 |
|
While trying to weekly report the quality of our software, We
had a lot of discussion about what numbers to use. None of the
quality calculations really represent reality. Actually, I believe
it's impossible the calculate code quality, because it needs human
interpretation. We have two pillars in our weekly quality report,
the first is a human pillar, the second is a calculated one. The
human factor we use is if code reviews were do The second pillar is the calculated one. The information we have, at this time, is code coverage. Because we work with a lot of "pre-unittest" code the developers weren't actually happy with the use of code coverage. This is the way we now use to represent the change in code over the last week and the effect the changes had on code coverage (a colleague came up with the calculation). Difference in coverage (percentage) over the last week = ((Ct - Cl) / T) - ((Nt - Nl) / T) These are the variables: Translated the percentage is the percentage of growth of covered blocks minus the percentage of growth of non-covered blocks. If this is a positive percentage there was a positive effect on the code coverage. If the percentage should be above some kind of norm. We chose above 75% = good and below -75% is bad. Another colleague suggested one of the following metrics: The last one isn't so much about quality, but more about risk. But the first one probably is usable. Probably we have to study some more on a usable metric and how to use it in our daily builds. If we have a better metric, I'll let you know. If you have any suggestions, please, let me know! |
ne. In
my opinion this is the most important one.They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
