Path: utzoo!attcan!uunet!decwrl!nsc!amdahl!netcom!mcmahan From: mcmahan@netcom.UUCP (Dave Mc Mahan) Newsgroups: comp.software-eng Subject: Re: How do you measure code quality? Message-ID: <11111@netcom.UUCP> Date: 27 Jun 90 06:17:38 GMT References: <10865@netcom.UUCP> <922@gistdev.gist.com> Distribution: comp Organization: Dave McMahan @ NetCom Services Lines: 175 In a previous article, flint@gistdev.gist.com (Flint Pellett) writes: >mcmahan@netcom.UUCP (Dave Mc Mahan) writes: >> In a previous article, Don.Allingham@FtCollins.NCR.COM (Don Allingham) writes: >>>What is a good measure of code quality? Management likes to use "bugs >>>per line of code". Is this really a good measure? Doesn't seem so to >>>me. And what is a line of code? Does it include comments? Do you make >>>adjustments for codings style? Program complexity? > >>Personally, I think there is only one standard, and it is set by the 'user' of >>the code. If the software does what it is supposed to do, the user will be >>happy... > >>Other metrics of 'code quality' should include the perspective of those >>programmers that come later in the project to do maintainence. Version 1.0 >>of a program could be great, but if the new programmer breaks a finely tuned >>system that isn't robust and works because the original programmer had special >>knowledge he didn't leave behind, the code is of poor quality in the eyes of >>the maintainer. I always shudder when I'm asked to modify someone else's >>existing code. Scrapping the current stuff is usually not possible due to time >>and cost, so the code must be re-analyzed and adjusted to take in the new >>features. > >>I guess the bottom line is, if the code does what it is supposed to do to the >>satisfaction of the user, it is 'good code'. If it contains bugs or puts major >>constraints on the user in the environment is was designed for, it could use >>some more work before it is ready for a final release. It may not get that >>extra work, but it could use it. > >>>Don Allingham > >I certainly cannot agree with this definition, because the concept of quality >is not one that lends itself to anything this simple. For code to be good >code, it has to measure up against more than just one yardstick: the measure >of "does it do what it was supposed to do" is only one yardstick. A few >simple examples should suffice to show what I mean. I would claim that for any given perspective (user, maintainer, coder, administrator, etc) that there is only one yardstick. It may be different depending upon the hat you wear, but for each mode there is only one. Those that wear multiple hats at the same time may have more than one yardstick. >Given: The code that does exactly what it is supposed to do to the >satisfaction of the user, works great, no constraints on the user, does >what is was designed to do, no bugs, in the environment it was designed for. > >However: If the following is also true, I believe anyone qualified to judge >good code is going to tell you that the code is not good code: > >1. The code is completely uncommented. (My personal yardstick: if you have > one line of code, there should be 1 line of comment explaining that > line of code, and at least 25% of the lines of code should have > comments on the line explaining them. I include documentation files > that explain usage, file formats, etc. in my list of required > documentation. Doesn't this fall under the 'hat' of the maintainer? A 'user' could care less if comments exist or not, since he can't ever see them. If one used an interpretted language such as BASIC and it includes comments, I argue that running the program and viewing the source code for comments requires wearing two different hats. I agree that a different hat provides a different viewpoint about what is and isn't good code, but the user could care less about the internal details. S/he just wants a program that gets the job done. Lack of documentation isn't important. The maintainer, however, is a different matter. Again, I would argue that lack of comments in the source falls under the catagory of the original programmer having special knowledge that wasn't left behind. (personally, I tend to agree with your rules of thumb for the percentages of comments. However, each person and program have their own view of what is correct). From the user's point of view, the code may be fine. From the viewpoint of the maintainer, it's an absolute living nightmare come true. Is there really any one perspective that is right for everyone? I think not. >2. The code doesn't document itself. If you've ever seen code where > all the variables are named "t1", "t2", "t3", etc., you know what > I mean. Once again, I claim this falls under the, "original programmer had special knowledge that he didn't properly leave behind". >3. You cannot perform even trivial additions to the code without major > amounts of effort. (When your user says "The product is great, can > you add and you have to say "Sure, for $10K" even your > user is going to wonder about the code quality.) Again, "original programmer ...." The user isn't going to wonder about code quality. The person paying the bills may, however. These two personna are not always the same individual. >4. The choice of language was inappropriate: 2000 lines of code were > written to do what 5 lines would do in another language. I feel this is a relative point. Is there really any 'quality' difference between a program that is 20000 lines of assembly vs. a program that is 5 lines of Lisp (or other language) which requires a 200K interpretter to run it? What is a 'line of code' in one language equivilent to when compared to another language? It is quite possible that the 2000 lines of code may be much faster than the other version that requires only 5 lines. What if the rest of the program is already written in the language of the 2000 lines, and switching to a more compact language form isn't even close to trivial? I've seen some pretty wicked-looking APL programs that are only 5 lines, but you would need 5 years of dedicated APL experience to figure them out. Quality code? You make the call. >5. The code re-invented the wheel. It is not great code to write your > own routines to do things the standard libraries do for you, even if > your routines work. It is not good code if your code could have been > driven from standard file formats and wasn't. IMHO this is bad form, but is it really bad code? Most probably yes, but who can say? Perhaps the redundant code was written to make the program truely portable across a large spectrum of machines. Is it then redundant and 'Bad form' just because the machine you are running it on has a better way? Wouldn't this conflict with item #6 below? >6. The code isn't portable. Well, maybe that isn't important to you, it > does work perfectly in the original environment. Once again, it may be non-portable, but is that a measure of bad code quality? It is optimal (IMHO) to write code that IS portable across machines as often as possible, but the obvious case of an assembly language program is clearly never portable (or hardly ever). Is this poor quality code? >7. Code complexity. This goes to the issue of maintenance referred to > before. One tool I use is a mccabe complexity analysis: I get a > number back for each routine telling me it's complexity according to > the McCabe model, and I know if I see anything above a 10 I better > go look at it and see if I can rewrite it in a better fashion. I'm not familiar with the McCabe model. It sounds like a good thing from what you write of. I feel that this might provide a good guidepost to code that is too complex, but is this always the case? To steal a phrase from many .signature lines (I think the orginal author was Alan McKay), "Simple things should be simple. Complex things should be possible." I don't feel that code complexity is a hard and fast good/bad indicator of code quality. Ever try to filter out satellite frequency shift from a local oscillator in 10 lines or less? Some things just take a lot of complicated code. >I could probably list a few dozen more things, but this posting is too >long already: but maybe that is the point: there is no simple definition >of what represents code quality. This is a statement I totally agree with. I was trying to write about the most common metric I use, the perspective of the end user. I feel the bottom line is that no matter how elegant the code is, if it doesn't do the job correctly, it's not worth the paper it is printed on. > In the meantime, don't >trust anyone who says they can define what quality software is in one >paragraph, because it cannot be done. I'm not sure if that was the message that went out, but it's definately not the message I was trying to deliver. The original poster asked for some ways to measure quality, and I gave him the ones I use to sell of the product. You are quite correct in stating that there are many more ways than one to look at what makes 'quality software'. >Flint Pellett, Global Information Systems Technology, Inc. -dave