Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!uunet!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!marick
From: marick@m.cs.uiuc.edu
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst
Message-ID: <38800009@m.cs.uiuc.edu>
Date: 14 Sep 90 13:34:00 GMT
References: <62927@lanl.gov>
Lines: 50
Nf-ID: #R:lanl.gov:62927:m.cs.uiuc.edu:38800009:000:1533
Nf-From: m.cs.uiuc.edu!marick    Sep 14 08:34:00 1990


/* Written  9:08 pm  Sep 13, 1990 by jlg@lanl.gov in m.cs.uiuc.edu:comp.society.futures */
> The main problem
> with assignment is not the operators, per se, but the fact that they are
> allowed _within_ an expression.  There have been several well conducted
> experiments on the effect of such operators on user productivity - the
> conclusion has been that assignment should be a statement level operator
> and _not_ an expression level one - at least, if you want to maximize
> user productivity.

By lost productivity, do you mean time spent discovering and
correcting errors where people wrote

	if (a = b)

when they meant

	if (a == b)

Did they study languages where that kind of error is less likely?  For
example, I doubt many Lisp programmers write

	(if (eq a b)

when they meant

	if (setq a b)

Were the studies of novice programmers?  How were costs calculated?

It's important to not to interpret experiments more broadly than the
data allows.  For example, were code reads used in the experiment?
With a code read checklist, such errors are readily caught, at low
additional cost.  If they were not used, the experiment says only that
value-returning-assignment raises costs in the absence of code reads,
not that they raise costs, period.

Because experiments require interpretation, I'd like to see citations.
Thanks.

(BTW:   I recommend this convention:

	if (5 == a)

instead of 

	if (a == 5)

Cuts down on errors considerably.  I saw this on the net somewhere,
but I don't know whose idea it was originally.)