Gregory Ewing <greg.ew...@canterbury.ac.nz> writes: > However, that's only a very small part of what goes to make good code. > Much more important are questions like: Are the comments meaningful > and helpful? Is the code reasonably self-explanatory outside of the > comments? Is it well modularised, and common functionality factored > out where appropriate? Are couplings between different parts > minimised? Does it make good use of library code instead of > re-inventing things? Is it free of obvious security flaws? > > You can't *measure* these things. You can't objectively boil them down > to a number and say things like "This code is 78.3% good; the customer > requires it to be at least 75% good, so it meets the requirements in > that area."
That doesn't reduce the value of automating and testing those measures we *can* make. > That's the way in which I believe that software engineering is > fundamentally different from hardware engineering. Not at all. There are many quality issues in hardware engineering that defy simple measurement; that does not reduce the value of standardising quality minima for those measures that *can* be achieved simply. -- \ “Spam will be a thing of the past in two years' time.” —Bill | `\ Gates, 2004-01-24 | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
