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