Andrew,
>This advice to more seriously consider the user and task is, I think,
>very good and I think doing so is important to rendering our results
>more scientific. Unfortunately, it seems less and less of the
>resulting work is directly relevant to the relatively low-level
>practices of coding by experts.
Not necessarily. Given a model of how people understand code I'm sure
it would be possible to derive some useful guidelines.
My interest is in understanding how people understand code, not
how they write it. These days most of the money spent goes into
modifying/maintaining existing code, not writing new code. This bias
continues to grow.
>I don't know of anybody willing to go through
>all the lists of coding guidelines and subjecting them to empirical
>test (Dr. Gould? Where are you?).
I think I can reliably claim to have seen nearly every worthwhile C
guideline (it helps being the designer & co developer of the C tool
used by the market leader in guideline enforcement www.prqa.co.uk).
There has been some empirical work done on what mistakes people make
(by looking at the code they write). A tradition I shall be following in.
> On the other hand, some authors
>of guidelines (hint, hint) might in the future wonder about whether
>including a cognitive psychologist as a co-author might be a useful
>endeavour.
Probably a good idea. However, I only got seriously interested in
cognitive psychology 6 months ago (half way, or so I thought through
writing the book). Now (2/3 way through, I hope) is probably a bit late.
>I think also it is a little unfair to ask psychology to be
>able to unambiguously determine the "right" things to do.
I would settle for knowing what the wrong things to do are :-)
>How many rules do you think govern programming?
Sheil quotes Brooks as estimating 10K, which sounds about right.
I have broken the C standard down into 2,500 sentences and am writing
to each of those. I could write 10 comments per sentence, so 25K.
And that's just at a low level. But it would include lots of stuff
about C running on cpus that very few people use (being a compiler
writer means I know lots of stuff about unusual machines). So that
25K doe snot reflect a 'real' developer, since few get to work on many
different machines. I am also excluding the higher level design stuff.
So I would be happy with 10K.
> How many exceptions
>to these rules? How do good programmers know when to apply them?
I think Ruven Brooks paper Int J Man Machine studies (1983) 18, 543-554
hits the nail on the head
>The answer: years of experience. I don't think you'll be able
>to write any reasonably length book that captures all of this
>hard-earned wisdom.
Does 2000 pages (current estimate) sound reasonable? But hey, who said
anybody would ever read it :-|
> The implication would be that becoming a
>good programmer is something that can be done in a matter of
>days or weeks. Guidelines can be thought of as the rules of thumb
Err, would you be happy with the software controlling the car/airplane/...
you are in being written to rules of thumb?
>ISBN 0-262-69191-4). Software development is far more of a craft
>than an engineering discipline right now (but I'm sure there's lots
>of people that would want to disagree with that statement).
It is at the moment. This is almost wholly due to the demand for bodies.
Companies are scared of testing developers in case they frighten off
the good ones. In what other area could people with little experience
manage to get jobs with such responsibility? The incompetent are
hiring the incompetent. Once the software field settles down, ie the
very short product development cycle lengthens as products mature and
markets saturate, the interest in true professionals will grow.
derek
--
Derek M Jones tel: +44 (0)
1252 520 667
Knowledge Software
Ltd mailto:[EMAIL PROTECTED]
Applications Standards Conformance Testing http://www.knosof.co.uk
