ryer@inmet.inmet.com (12/06/89)
I am rather pleased with the note stream so far: A request for quality metric definitions, followed by several days of silence (from thousands of people), followed by an intelligent refutation of the premise. However, I will venture to add a few cents worth. Here are some metrics of quality: 1. How complex is the program in comparison to the simplest possible program that performs the same function? 2. Are the user-visible parts (inputs, parameters, listings, etc.) "friendly" -- easy to use/remember/understand, idiot-proof, etc? 3. Where complex combinations of features are used, is it elegance or capriciousness? 4. How fast will it execute in comparison to the optimal equivalent version? 5. Are the names of types, blocks and objects chosen to make the semantics intuitive (without being cumbersome)? 6. Do the comments answer the questions a maintainer is most likely to ask? 7. Has the programmer anticipated the type of changes/extensions that are likely during maintenance and designed the program so that they can easily be added without breaking something else? 8. Does the program do reasonable things when the inputs are unreasonable and outside the intended scope of the program? 9. Does the terminology used reflect conventional useage in the application domain? 10. Are there parts which have a high potential for reuse in other programs? 11. If a maintainer introduces an error in one part of the program, will the other parts recover, detect it, or crash-and-burn? 12. Does it use standard concepts, algorithms, and data structures where appropriate (with identification of their names/origins) or re-invent the wheel? After you've implemented these, I will spend another half hour and give you a dozen more. :-) Mike Ryer Intermetrics