Andrew,
>But I was really arguing a rather more philosophical point about how
>much further away cognitive models are from justifiable design
>requirements or programming guidelines. The early work tried to
>directly tell you if one program format worked better than another.
>Use n-space tabs! Avoid this construct!
As a 'user' of the result of this research this is all I really want to know.
> By building a cognitive model
>instead, you're a good number of steps removed from figuring out such
>things.
Which of course means I have to do some thinking. Something I always
recommend that other people do...
> The design implications seem to tend towards very simple and
>low level, or the basic and very general: don't tax memory; make
>things consistent; make stuff learnable. I was arguing we seem to see
>few specific programming-related recommendations coming out of the
>cognitive modeling work (yet we still see some coming out of the simple
>performance comparison type of work).
It would be asking a lot for psychologists to do my job for me.
I really need to learn about these models and apply them to my own area
of interest.
>What kind of guidelines are you thinking of?
Guidelines are claimed to be useful for a number of purposes. In the
case of MISRA increasing the reliability of software. My aim is to use
them to reduce the cost of ownership of software.
> You mention the guideline
>to use meaningful names for identifiers.
As an example of a bad guideline (but one that lots of companies having
in their guidelines document).
> I admit I'm rather hard
>pressed to think of any reason to employ a cognitive model to justify
>this guideline, but I suppose it could be invariably wrong.
There are some readability issues associated with close spellings and
similar looking characters (1 and l, one and ell). Nothing earth shattering.
>(Maybe it is a worthwhile project to get together a list of coding
>guidelines for which there exist psychological justifications and/or
>experimental results. This would obviously be something you're
>interested in.)
I have been trying to do this, without success.
> > >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. [..] I am also excluding the higher
> > level design stuff. So I would be happy with 10K.[..]
> > Does 2000 pages (current estimate) sound reasonable? But hey, who said
> > anybody would ever read it :-|
>
>I'm not sure if I understand you correctly: you mean you've described
>the C standard in 2.5K sentences
The C standard (or at least the language, excluding library) contains
2.5K sentences (sort of, depending on how semicolons and bullet points
are counted). The library is another 6k sentences (but I am not covering
that in any detail).
> and have about 10 rules of programming
>(or guidelines, if you prefer) that apply to each of those sentences?
I started to write all I knew about each sentence. But a lot of this
knowledge was out of date, or applied to languages (there is some cross
language discussion) that are rarely used, or applied to now defunct
hardware. So I stopped writing everything I knew. So now I am probably
writing, on average, 2-3 'information packets' per sentence. I claim I
could do 10 (but them I have been known to claim all sorts of things).
I was trying to equate this number to the 'rules' described by Brooks.
Guidelines average perhaps 0.8 per sentence. But them I am involved
with an existing product that contains over 1,000 rules.
> > Err, would you be happy with the software controlling the car/airplane/...
> > you are in being written to rules of thumb?
>
>You mean like programmers applying the guideline "use meaningful
>identifiers" when nobody knows what that really means? I wouldn't
>dream of flying on an aircraft built using such fuzzy rules. ;-/
You probably already have (but I you may have managed to avoid driving
in a car that uses them) and watched a TV and own a CD player and ...
A interesting cognitive rule could apply to the nesting of if statements:
if (x > 3)
if (y < 33)
if ((z > x) && (PP == 11))
and so on
The usual guideline in this area is to forbid the nesting of if's below
a certain depth (on the basis that such usage is harder to understand
{it is also a good indicator of low programming skill}). A simple rule,
but one that something leads to the source becoming less readable.
A more sophisticated rule would take account of the inherent complexity of
each controlling expression (something an experienced developer would do
{and the sort of person who gets very uptight at being forced to follow
rules that degrade the quality of code}).
I would like a formula that would tell me how complicated a nested if
statement was likely to be to understand. This formula would tell
me that the above construction had understandability complexity 13
(for instance). Trying out various other possibilities I would find
one that had a value of 8. I could then happily rewrite my code in the
knowledge that I minimised the risk of a subsequent read misunderstanding
what I had written.
>They said:
>
> we are uncertain whether, at present, there exists any process to
> articulate a core body of knowledge in software engineering that will
> directly contribute to the solution of the software quality problem.
This looks interesting. I will follow it up.
>In the bok_assessment document, it claims that the core body of
>knowledge for credentialed engineers would need to "reflect actual
>achievable good practice". I should think that some of your guidelines
>would be related to such a body of knowledge.
I wish. The key phrase here is "actual achievable". Given the amount of
money most companies put into quality assurance what is actually achievable
is not a lot. The knowledge is there, the tools are there.
What we need are software companies being sued for serious money,
over faulty products. Hit them where it hurts. Then they will invest in
quality.
Sad, but true.
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
