Why whitespace denotation of blocks doesn't work.

Bob Hays, Computer Geek rhays at interaccess.com
Sat Jun 17 09:12:03 EDT 2000


On Sat, 17 Jun 2000 07:49:43 GMT, olczyk at interaccess.com (Thaddeus L.
Olczyk) wrote:

The following are just my opinions to take or leave (probably the
latter) as you wish.

>1) The first is rather stylistic and may not appeal to most, but I
>have often found it useful. When debugging code I often put in
>code to help me figure out whats happening. I also avoid indenting
>such code so that it easy to remember where it is later when I want to
>take it out. An example ( assuming I use begin and end to denote
>blocks ):

I've gotten in the habit of putting the comment DEBUG on such lines in
all programming languages; depending upon indention is very dangerous
for debug lines since someone else may reindent the line properly and
then it gets left in (since they didn't know it was a debug line).

>2) You can easily insert a tab introducing a bug.  Consider the
>following code ( similar to a bug I recently fixed ):
{Example skipped}
>Initially the line in error was indented correctly, but someplace
>along the line the extra tab was introduced. A lot of effort then had
>to go in to finding this bug. With begin...end or braces this is less
>likely to happen.

Yep, this happens.  Its a tradeoff - speed vs. occasional extra work.

In addition, I had an example, in C++, where someone had commented out
a block of code, but then had an embedded inline comment inside that
block, and, to top it all off, the less-than-desired commented out
block would still compile - the guy worked on that bug for a day
before coming to me.  I loaded it into emacs and the color coding told
him immediately what had happened; he was very ashamed and angry, but
I told him sh*t happens:-).

>3) Finally. Python is a language where it is almost easy to write
>extensible programs. To illistrate what I mean consider this example
>of a python program I recently wrote:

Here's were we will agree to disagree, I think.  I think its way
faster and easier to extend Python stuff than C++ (and Java) due to
the lack of compile/link cycle and due to inheritance inside of
Python.  Yep, you have to be careful how you indent, but if you have a
good editor it will cut/copy/paste as-is without reindenting.  I see
more problems due to bad cut/copy/paste reuse in all programming
languages than I do from mis-indenting so far.

My interesting tale is a consultant I have right now working on some
production Python code.  He started making changes using vi and
realized that we had carefully used spaces for indention (I had that
holy war in a previous life [at a shrink wrap vendor that had to run
on almost anything], and we finally agreed that tabs were evil in a
cross-platform environment).  He started using spaces and now isn't
having problems.

>Anyway I hope this causes TPTB to think about how blocks should be
>handled in Pyhton 3000.

My personal moral - no programming language will save you from
yourself - use good tools and do your best.

Have fun! - Bob

--
Bob Hays                           "Discipline is never an end in
181 W. Madison                      itself, only a means to an end."
MS 4000                            -- King Crimson
Chicago, IL  60602                 "Whoever flees history will be
(312) 904-4668 (V)                  pursued by history."
(312) 904-5774 (F)                 -- Janusz Korczak
Bob.Hays at abnamro.com               "Faster! Faster! Until the thrill
rhays at interaccess.com               of speed overcomes the fear of
                                    death."
                                   -- Hunter S. Thompson
                                   "Security is very frequently the
                                    commencement of calamity." 
                                   -- Paterculus
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d+(-)@ s+:+ a C++(+++)$ U$ P+$ L@ E+++$ W+++$ N++ !o-- K--? w$ !O 
M$ V@ PS+ PE !Y+ PGP t !5-- !X !R tv+ b++() DI+ !D- G-- e++ h--- r+++ 
y+++** 
------END GEEK CODE BLOCK------



More information about the Python-list mailing list