> It was *supposed* to go to povray.off-topic...how did your post get
> back here? Followup-To is again set to povray.off-topic...

If you expect a reply, we have to select a newsgroup which is valid.  I'm
not showing the presence of that group, and get an error.

> > # end, # endloop, # end whateverthehellyerstopping       :-)
>
> I really don't like this...it's a comment, not part of the program. And
> if you mess up with it, there won't be any error or warning to let you
> catch the problem.

Actually, an IDE COULD catch any rule you wanted to enforce.  But I was
mostly joking.


> But you are writing in English, not Python and not any other programming
> language. And grouping different concepts by separating them with white
> space is different from specifying which block an instruction is in by
> it's level of indentation. Even when writing instructions in English, I
> tend to take a more structured approach, grouping each stage together
> with it's sub-stages.
> And even English sentences have a termination character, the
> period/exclamation point/question mark.

English (and all other human languages) ARE programming languages.  The
machine they run is a computer we call the human mind.  The only difference
is one of complexity and the amount of ambiguity which is tolerated.  No
differences in principle.

English is obviously not the only language.  Some amazing thoughts have been
expressed in languages which use NO punctuation, with meaning established by
rules of context and convention.

But punctuation is a helpful invention.  As is the use of white space.  It
is ALL expressive, and nothing should be rejected as a potential tool.


> Alright, I understand now...funny how that got interpreted as exactly
> the opposite of what you meant.
> Hmm...would white space count in your comments? ;-)

That's because ambiguity is inevitable in implicit conceptual speech.  Your
interpretation was POSSIBLE, but just how probable was it that I was
completely contradicting myself?  Thus the importance of context (both
linguistic and psychological), and even the greatest punctuation cannot
resolve every implicit referent.

> I think an enforced minimum would just result in a lot of low-quality,
> "space-filler" comments, or even strings of garbage characters.

Just as no enforced comments can result in no comments at all.  Make it
foolproof and some will reinvent themselves as better fools.  At least, such
a scheme would only serve as a REMINDER that commenting is a good idea-- or
a requirement if one is on a programming team.  Anyone on my team who
habitually substitutes garbage characters for meaningful comments would soon
be granted an extended vacation.


> > As for comments to the right, as opposed to mixed within the code,
> > that's an excellent scheme which I've been using for over twenty
> > years, all the way back to assembler code.  With high level languages
> > the commenting can be more sparse, but should still be GENEROUS.
>
> If you say so...20 years of experience certainly beats what I have. It
> just seems like a huge pain when writing or even just reading
> comments...

Yes, it is FAR easier in the short term to slap uncommented code together.
The HUGE pain comes when it grows to over 20 pages.

I once read a book about a language called Forth.  When I finally received
the software, I wrote a screen editor within the first 24 hours.  Worked
pretty well.  The next week, I could not read what I had written.

> especially when you are maintaining the code and the length
> of lines keeps changing.

That's what smart editors are for.

> And what if you have a really long line? Do you just skip the comments
> over it? BTW, how does Python react if you break a very long line
> (function parameters, for example) into several lines and indent them
> for readability? I've got some horrendous examples of this...

There is ALWAYS a way to do things readably.

>> The Goddess of Reality merely smiles.
> Cough...Java...ahem...

Shhh... you want to start a Holy War here?  8-O

Post a reply to this message

On Thu, 8 Feb 2001 14:09:35 -0800, OpenMined wrote:
>(I will have to say, however, that to "notice it after the code has been
>sent to production" would suggest a breakdown in- or absense of- adequate
>testing protocols.  In my view, any programmer which creates/modifies code
>without creating/using in parallel an exhaustive every-state module testing
>regime- as much or more work than writing the original code- simply has not
>finished the job.)

Such testing is impossible in an environment such as the one we work in, 
where the set of possible conditions is dictated by how many "innovative"
ways programmers we'll never meet can find to do the same thing.  The 
"input" to our application is other peoples' programs, and they're often
broken in strange ways.

Who would have thought, for example, that a team of crack monkeys at a
firm I won't name would have decided to draw focus rectangles by calling
ExtTextOut with an empty string and with the "background opaque" flag 
set to TRUE, once for each side of the box?

Anyway, the point is, unit testing and integration testing only go so far.
It's very possible for errors to slip through such processes, and anything
that tends to make it easier to make such errors is a bad thing.  In my
view, that makes significant whitespace a bad thing.

Notice that I'm not saying it's a bad thing for everyone.  It's just not
something I'll ever do, because unlike structured programming and object-
oriented programming, it has no perceptible advantage over enforcing the
whitespace rules at checkin time, and far more caveats.

>So, when I speak favorably of Python's use of white space- a concept I would
>enjoy seeing extended, as mentioned- I am thinking in terms of new projects,
>with programmers who have fully adapted to the needs of the programming
>environment, and with a project for which the ongoing needs are as important
>as the need to get it done and out quickly.

If I were starting a new project, I would put rules in the revision
control system to enforce the style guide.  That solves the problem of
whitespace without causing potential bugs, and it can enforce other rules
too.  IMHO, presentation and syntax should be separate.  I understand that
you don't agree, so I suggest we just agree to disagree.

As to comments, I couldn't agree more.  In fact, I use the same prototyping
method you do: write the pseudocode, then fill in the code (but I fill in
the code between the comments, rather than to the left of them.  That makes 
them less confusing for the visually-impaired members of our team to read.)
We also enforce comments on all closing braces, for the benefit of the same
people (who often have punctuation turned off in their screen readers.)  In
fact, I'd be very surprised if the POV 3.5 code ships without at least one
} // end if

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message