Re: not enough real programmers?

[seebs@plethora.net (Peter Seebach)]

In article <37b33ae8.15667869@news.pandora.be>,
Luc Van der Veken <lucvdv@null.net> wrote:
>I agree - I overdid it with the intent of making the principle
>clear, in fact in my real code my loop counters are usually i,j,k
>etc., and ix, iy, iz etc. when they're indexes.

Yeah.  :)

>OTOH, in my larger sources, you might encounter *really* long
>names for global variables and functions - things like
>AllowSendSingleSetting (an actual example, and not even the
>longest - no leading 'b' because it's obvious enough that it's a
>boolean value).

I'd probably give it a different name, such as
	send_single_setting_ok
or
	allow_send_single_setting
or perhaps
	flags.single_setting
but I agree in principle.

>In a real specimen the variables and arrays wouldn't be called
>what I called them now - but not something generic like "dest"
>and "src" either, unless when the function itself was a real
>generic one.

Ahh.  I was assuming this was a moderately generic
function-to-operate-on-arrays.  :)

>> 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.

>You're right - I don't know where I got the idea.

This is one argument against a lot of comments.  A wrong comment is worse than
no comment.

>I've got a habit of keeping my lines short though, which is why I
>put longer comments before the code they apply to, rather than
>letting them run into columns 70+.

Fair enough.

>- I thought the lack of '{}' would make it clear that this was
>intended as just a snippet of a larger routine, and I hate
>declaring variables in the middle of code.  You'll never find
>something like "for(int i=0;..." in something I wrote.

Interesting.  I am firmly convinced that a variable which does not survive
a loop should be local to the loop if possible.  Locality of reference is a
maintainability win.

>- ix is a prefix I often use to indicate that it's an Integer,
>and an indeX at the same time.  Out indicates that it's an index
>into the outgoing data (this could have been ixDest or so as
>well, but I find Out more readable - just a matter of taste).

I hate type-prefixes; if you can't immediately tell what something is, your
name is bad.  :)

>You have the right to have your own opinion, but in the middle
>(or at the end) of a complex routine, I prefer having variable
>names that tell you what they are, and what they're there for.

I agree - but 'i' is good enough to tell you 'thing-on-which-I-iterate',
and 'what it's there for' should be obvious in context.

Long names are harder to read.

>> >   if(InArray[iInIx]) OutArray[ixOut++] = InArray[ixIn];

>> Furthermore, the long names made you use the wrong name for the first
>> subscript.

>No, actually it's changing the name after I wrote the code and
>forgetting one that did that :-)

Yes, but you'd never have missed it if the code were easy to parse.

>See previous posts in this thread - I didn't invent the exercise.

Ahh.

>> 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];
>> which would be *much* more informative.  Also note that indentation can help
>> you make your intent clear here.

>Superfluously breaking up lines (what you demonstrate here IMO)
>actually makes the code less readable.

That's not superfluous.  The eye handles indentation very quickly; indentation
shows flow of control.  Splitting the 'if' from the statement it controls
lets you see the whole thing instantly.  If you merge it
	if (src[i]) dest[j++] = src[i]);
looks right at first parse.  Minimize the amount of hunting people need to do.

>It's exactly to avoid reading errors that I try never to split
>single conditional statements up over two lines.  Indentation, in
>my sources, means either that it's a new code block (like the
>body of a loop or multiple statements in an 'if' body), or that
>it's a continuation of a long statement (if, and only if, it
>won't fit on one line - but as I said, I normally try keep my
>lines short).

Ahh, but the if body *is* a block, logically.  (And in C9X, it's been
declared to be its own block.  Long story.)

>This whole thing is best described in words as a single "if it
>ain't zero, copy it" - so I deliberately try to keep it on a
>single line.

I still say that breaking the clauses apart makes for clearer code.

>See above for my feelings about mid-code declarations.
>IMO, only sloppy programmers (who forgot that they would need
>them when they were declaring variables, and are too lazy to move
>the cursor back up) use them.  A "for" statement is burdened
>enough with the elements it needs of its own - adding a
>declaration only makes it less readable.

Unless the declaration really is part of the for.

We don't say
	there are groups G and H.
	some day there will be an element g.
	some day there will be an element h.
	blah blah blah
	for any g e G ...

because you declare something when you are saying what it is.  If 'i' is
the loop variable, and has no function other than 'loop variable', it should
be declared as part of the loop.

In C, I often do
	{
		int i;
		for (i = 0; i < N; ++i) {
		...
		}
	}
so you know that i only does that.

>I often notice that a large part of my C++ code would compile on
>a C compiler (if it understands C++ style comments, like most do
>nowadays), but maybe that's only because I was already
>programming in C before C++ appeared on the scene.

Probably.  Actually, as a technical note, no C compiler "understands C++
comments" - if it does, it's failing to conform to the spec, and it's not
a C compiler.

>Today I prefer to use C++ BTW, also when C would do nicely,
>mainly for its strict type checking - so that's what I was doing
>here too.

I prefer C because it has saner type checking.  ;)

>> 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)
>> and for complete lack of indentation.

>The same is true for i and j - and that's how it was *supposed*
>to be :-)

It's not, though.  i and j are primary and secondary iterators, which is
correct.

>But if you say it was *less* flawed, I probably wouldn't like to
>[have to] maintain your code (at least not anything above 1000
>lines).

Well, all I have to say is:  The terse example was more correct.  I believe
the reasons for which it was more correct are fundemental to terse code versus
excessively verbose code.

-s
-- 
Copyright 1999, All rights reserved.  Peter Seebach / seebs@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Will work for interesting hardware.  http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!