RetroSearch Browse

Thu Mar 4 06:57:30 EST 2010 · http://mail.python.org/pipermail/python-list/2010-March/720648.html

Gregory Ewing <greg.ewing at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-list/2010-March/720648.html below:

Docstrings considered too complicated