[TUHS] 80 columns ...

[norman@oclsc.org (Norman Wilson)]

Nemo:

  And for that reason, I have never used Python.  (I have a mental block
  about that.)

====

I used to feel the same way.  A few years ago I held my nose
and jumped in.  I'm glad I did; Python is a nifty little
language that, now I know it, hits a sweet spot twixt low-level
C and high-level shell and awk scripts.

Denoting blocks solely by indentation isn't at all bad once
you do it; no worse than adapting from do ... end to C's {}.

What still bugs me about Python:
-- It is unreasonably messy to give someone else a copy of
a program composed of many internal modules.  Apparently
you are expected to give her a handful of files, to be
installed in some directory whose name must be added to
the search path in every Python source file that imports
them.  I have come up with my own hacky workaround but it
would be nice if the language provided a graceful way to,
e.g., catenate multiple modules into a single source file
for distribution.
-- I miss C's style of for loop, though not often.  (Not
quite everything can be turned into a list or an iterator.)
-- I miss one particular case of assigment having a value:
that of
	while ((val = function()) != STOP)
		do something with val
Again, there are clunky ways to work around this.

As for 80 columns, I'm firmly in the camp that says that
if you need a lot of indentation you're doing it wrong.
Usually it means you should be pulling the details out
into separate functions.  Functions that run on for many,
many lines (once upon a time it was meaningful to say
for many pages, but no longer) are just as bad, for the
same reason: it's hard to read and understand the code,
because you have to keep so many details in your head at
once.

Likewise for excessive use of global variables, for that
matter, a flaw that is still quite common in C code.

Having to break an expression or a function call over
multiple lines is more problematic.  It's clearer not
to have to do that.  It helps not to make function or
variable names longer than necessary, but one can carry
that too far too.

Style and clarity are hard, but they are what distinguishes
a crap hack programmer from a good one.

Norman Wilson
Toronto ON
(Sitting on the lower level of a train in Texas,
not on a pedestal)