[I kept wondering why this message didn't appear from the listserv. I
"replied" only to Derek. boy do I feel stupid.]
I don't have or know of any papers on the subject but do have a thought.
The first thought that popped into my head was that almost certainly the
effect is based largely on context of which, here, there appear to be two
fairly stong components. First, the existing code would strongly bias the
brain to focus on the method in use rather than some alternative.
Second, the
task is to add (or delete) one thing not to modify/fix the code.
Thus, the first things that pops into the programmer's mind will almost
certainly relate to modifying the existing code (within its current
form) to
do _just_ the one extra (or less) thing.
Probably one could test this notion relatively easily by adding or changing
the context, e.g., state the problem in terms of "currently it does ...
and we
want it to do ..." (thus, allowing the programmer to think about her own solution
approach before seeing the existing code) OR requesting that the programmer
not only make the change but leave the code in as good a form as possible
(allowing her to have a larger goal than merely making the code do X).
... philip
--
J. Philip East
Associate Professor of Computer Science Education
Computer Science Department, University of Northern Iowa
Cedar Falls, IA 50614-0507 [EMAIL PROTECTED] 319.273.2939
Derek M Jones wrote:
> All,
>
> I have just been reading the Adaptive Decision Maker
> by Payne, Bettman & Johnson.
>
> They make the very good point about people using
> different decision strategies to solve problems with
> effectively the same cost/benefits, but worded in different
> ways.
>
> The same issues occur in programming. For instance, if
> I want to execute different code, depending on the value of X.
> I can write:
>
> if (X == 1)
> do_this();
> else if (X == 2)
> do_that();
> ...
>
> or, I can write:
>
> switch (X)
> {
> case 1: do_this();
> break;
>
> case 2: do_that();
> break;
> ...
> }
>
> If there are only two values I suspect that most developers
> would use the nested if. If there were 10 values, most would use the
> switch. The change from one construct to another would happen
> at some point in between. I suspect that different developers use
> different criteria for selecting when to change. But that is not what
> I want to talk about.
>
> When maintaining code that has, say a nested if, and an
> extra situation needs to be handled, X== 3. I suspect that developers
> would simply add another if statement, even if they would have
> changed to using a switch, when writing the code from scratch.
> On the next round of modifications I suspect that the developer
> would again add an if (X == 4) statement, not changing the code
> to use a switch, and so on.
>
> The reason for this behaviour, in my experience, is a decision strategy
> based on minimisation of risk. That is the fewer changes that are made
> the less chance of introducing faults.
>
> There is also likely to be time pressure.
>
> Going the other way (having a switch and deleting the case labels
> one by one). I can see myself changing to an if statement once the
> number of labels reaches two. Certainly by the time it reaches one.
> But I also know developer who would probably leave the switch statement
> in, even after all the case labels had been deleted and it was empty.
>
> So my question is about decision strategies in selecting which
> programming construct to use. Does anybody know of any papers
> on the subject? I cannot find any.
>
> 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
>
- Automatic footer for [EMAIL PROTECTED] ----------------------------------
To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss
To join the announcements list, mail [EMAIL PROTECTED] subscribe announce
To receive a help file, mail [EMAIL PROTECTED] help
This list is archived at http://www.mail-archive.com/discuss%40ppig.org/
If you have any problems or questions, please mail [EMAIL PROTECTED]
