Re: not enough real programmers?

[Brian.dot.Inglis@SystematicSw.ab.ca (Brian Inglis)]

On Wed, 11 Aug 1999 17:29:48 GMT, seebs@plethora.net (Peter
Seebach) wrote:
>In article <37b19d82.1187858@news.pandora.be>,
>Luc Van der Veken <lucvdv@null.net> wrote:

[snip]

>>As for the last question, an example: there's a huge difference
>>between saying "[among other things] a good programmer writes
>>code that's maintainable", and actually writing maintainable
>>code.
>True.  You need to push a little.
>>// Watch this: iSize must be > 0 !!!
>>ixOut = 0;
>>for(ixIn=0; ixIn < iSize; ixIn++)
>>   if(InArray[iInIx]) OutArray[ixOut++] = InArray[ixIn];
>>return ixOut;		// Return new used size
>>-------
>>for(i=j=0;i<n;i++)if(a1[i])a2[j++]=a1[i]; return j;
>>-------
>I would consider both to be "bad" code.  I think the second is more
>trainable.  'i' is a better name than 'ixOut' for the same reason English
>has words like "it" or "he".

And both generic variables and IIRC modifier? pronouns or
referents? are "bad" when clear communication is required. 
There is never an "i" object in real problems, maybe a "this"
sometimes, but only one of them. 
Using "i" and "j" is like using "it" twice to refer to two
different objects. 
What's wrong with "src" and "dest" or "from" and "to" in the
example above? 

>People who litter their code with additional clutter are wasting a lot of
>time.

That should include using arrays where pointers better express
the function to be performed. 

>Don't believe me?
>PeopleNoun PNWho VerbLitter TheirAdjective NounCode PrepWith
>AdditionalAdjective ClutterNoun // note subordinate clause // AreVerb
>WastingGerund ArticleA LotNoun PrepOf NounTime.

Warts are a pain because if you change a variable's data type,
you have to change the name everywhere it occurs: praise be to
word delimiters in regexps. Be glad you're not a Windows
wart-monger with "visual" (read manual) tools ;^> Will someone
please lose the Simonyi notation "standard" wherever analysts
disposed of systematically numbered program and function names,
in favour of really meaningful names. Numbered names were
marginally usable only if you spent years or decades working with
the same code base. Who does that nowadays? "Where's the cross
reference list of numbers against descriptions for that quick
code change you need done in the next hour? Oh! Guess you won't
be paid tomorrow, eh?"

>Let's review:
>>// Watch this: iSize must be > 0 !!!
>This comment should have been directly on the line with the for loop,
>probably, but in any event, it's a stupid warning, and possibly wrong.  If
>iSize is less than zero, Nothing Happens, and we return 0 - indicating that
>we did nothing.  This Is Correct.  So the warning is wrong.
>>ixOut = 0;
>'ixOut' is undeclared, but it's a stupid name.  "ix" tells you basically
>nothing.  "Out" isn't a very good name, and the length of the name will impair
>reading later on.  I'd probably do
>	int j = 0; /* count of used items in new array */
>and let the reader's natural ability to understand pronouns do the magic.

Or call the object "used" or "usedcount", lose the mathematical
definition, and make the code look like part of a program. We can
use 31 characters for variable and 255 for files nowadays :-)
Writing, reading and remembering hordes of definitions is a total
waste of time when a tiny amount of thought and additional typing
would eliminate the necessity of doing so. 

>>for(ixIn=0; ixIn < iSize; ixIn++)
>Same problem with poorly chosen names.  Gratuitously hard to read.
>>   if(InArray[iInIx]) OutArray[ixOut++] = InArray[ixIn];
>Furthermore, the long names made you use the wrong name for the first
>subscript.  Use simple names because both reader and writer will remember them
>better.  It's fairly unusual to be discarding zero-valued array elements
>(after all, if location didn't matter, why were they in the array), but I'll
>assume it's intentional.
>Same problem with array names. "InArray" tells you nothing you can't see when
>you read the code, but it makes it harder to read the code.  I would have done
>	if (src[i])
>		dest[j++] = src[i];

Meaningful array object names, at least, if not the indexes. 

>which would be *much* more informative.  Also note that indentation can help
>you make your intent clear here.
>>return ixOut;		// Return new used size
>Did I mention you're using C++ comments in what appears to be C code?  If
>this had been intended as a C++ program, you would have used
>	for (int ixIn = 0; ...
>so I assume you're just being careless with comment styles.
>Over all, the "terse" example was flawed, but less flawed.  It gets demerits
>for poor naming (a1 and a2 don't tell you which direction you meant to go in)

Neither do i and j!

>and for complete lack of indentation.
>HTH.  HAND.
>-s

<flame>
I strongly believe that mathematicians, physicists and engineers
should not be allowed to do serious programming tasks until they
have been weaned from writing program code as if it were nothing
more than mathematical formulae. 
</flame>
The preceding was a party political broadcast on behalf of the
"Write Programs, Don't Formulate" Party!

Even mathematical algorithms are more comprehensible if recast
with meaningful names instead of placeholders. 
Consider contexts in which the same symbols are used to express
different meanings: is V an EMF or a potential difference, and at
which point or between which points is it being measured, and for
what purpose? 

Compare early programs written in Basic and ForTran to similar
code written nowadays in HLLs: do you really consider the code
littered with A1, B2, C3 and I, N, R, S more readable? Is that
any better than positional notations like $1 etc? I think not!
They each require the programmer perform an extra translation
step that can be easily eliminated. Variations in word lengths
and shapes also help to make code more readable, more quickly. 

Ease of comprehension and communication is the key in programming
nowadays as the projects get larger, the timeframes get shorter
and the uptimes longer. Recent projects expect and accomplish
more in a year than would have been thought possible in five a
decade ago; they would still be thought impossible in many shops,
with access only to ancient software technology, and no real
programmers to spearhead the push. [back somewhat on topic] 
My concern is with small pieces of code that can grow to be
significant parts of a large body of mission critical software:
code has to be comprehensible and changeable or fixable at 03:00,
before the coffee pot has had time to warm up, and the programmer
time to wake up. 

This is intended as a pointed attack on practices, not a personal
attack on opinions: we've all got decades of this in this NG -- I
don't want to be condemned to only lurk on CLCM forevermore.
HAND, eh?

Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
-- 
Brian_Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
				use address above to reply