Why whitespace denotation of blocks doesn't work.

[Thaddeus L. Olczyk]

On Mon, 19 Jun 2000 06:30:20 -0500, "Bob Hays, Computer Geek"
<rhays at interaccess.com> wrote:

>
>Good for you - you've been perfect and never, due to time constraints,
>checked something in that had a debug line in it.  Congrats!
>
Gee and guess what? I actually put in revision logs that fairly
describe my changes most of the time ( some times it can be difficult
or impossible, if you limit yourself to roughly ten lines, which you
should ). It's the little things like this ( as sports announcers like
to point out ) which seperate the amateur from the proffessionals.

>>>>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.
>>What increases in speed do you get by having to type braces?
>
>The code can be typed in much faster; its SLOWER to type in the
>braces.
>
Are you saying that you should choose a programming language based on
how long it takes to type in things? If so then you should be using
perl not python. The experts all agree that it is much faster to type
in perl than python.

Me, I prefer a language which helps me write good code. Faster to type
or slower to type doesn't make much difference to me. Of course if you
want something that is faster to type, you can always go to perl.

>>>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:-).
>>>
>>But that's the point. His code was illegal, it wouldn't compile. Easy
>>to catch with emacs, and the compiler will catch it too. The little
>>typo I show is easy to make and perfectly legal code. Its hard to
>>accidentally bump against a keyboard and make a similar nasty typo.
>>EVen something that looks like it might work like }{ would have to be
>>put in just the right spot.
>
>No, you didn't read carefully.  His could *WOULD* compile, but it ran
>somewhat wrong (obviously) and he wasted a sinful amount of time and
>energy trying to find the problem.
>
Your right I didn't read all the way in. ASAIK there is no way
to commant out a block of code, so that it contains a comment,
which causes part of the code not to be commented, and still compile.
You can do everything up to still compile, but it should not compile.
Care to give an example?

>>>>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.
>>>
>>I think you misunderstood what I said. I think that Python is not now
>>easily extensible do to the  problems with whitespaces. If that were
>>fixed then Python would be easily extensible. 
>{lots removed}
>
>But I do understand.  Good reuse would be to not copy but to reuse via
>inheritence or reinvocation - copy/paste reuse is always fraught with
>problems, and that's part of what OOP should help avoid (although I've
>always thought structured programming (SP) could deal with this
>problem also - its code size that limits SP).

No you don't. Did you afctually try to read the part I snipped? Guess
not. You need to cut/paste code ( aka move ) when refactoring. Many
examples in Fowlers Refactoring involve moving code. Just one, page
144 moving the overDraftCharge from Account to AccountType. Often
refactoring can't be done without moving code.

Example:

you have this bit of code

...
if x in xList:
      x.dosomething()
      x.dosomethingelse(y)
      if x.meetscondition(y,z):
          z.fixthings(y)
...

Some place far away, you realise that you are about to type
...
for a in xList:
      a.dosomething()
      a.dosomethingelse(b)
      if a.meetscondition(b,c):
          c.fixthings(b)
...
So what do you do?
Do you just type in the code? ( Great example of reuse )
Do you create a function and type in the code?

def foo(x,y,z):
      x.dosomething()
      x.dosomethingelse(y)
      if x.meetscondition(y,z):
          z.fixthings(y)

and change the code to

if x in xList:
   foo(x,y,z)

and 

for a in aList:
    foo(a,b,c)

Or do you move the code from the first routine to the function?