Python factoids... after 3 three years.

[Harry George]

Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> writes:

> On 7 Oct 2003 07:18:02 -0700, randall_young at hotmail.com (Randy Young)
> wrote:
> 
> >3  By far and I mean by a ton, the best language to use, put down, and
> >then pick UP AGAIN. Shortest learning curve to get back up to speed on
> >the toolset, and the code you wrote to do the initial task.
> 
> You've just got me curious about this. I certainly have no complaints
> about Python in this regard, but in general I think code readability
> depends on the programmer more than anything.
> 
> Being a packrat, I still have pretty much all the code I've ever
> written (excluding that written in defence companies) since I retired
> my old Commodore 64. Actually, I even have some old C64 source code
> that I managed to recover from the tapes into an emulator! This seemed
> a bit extreme, though.
> 
> In the end, I decided to go for some 68000 assembler code I wrote for
> an old college project in 1992 (one component in a distributed
> 'environment control system' using what the college called 'flight
> boards'). I can assure you I haven't read this code for a long time -
> it's only a couple of years later that I retired my Atari ST and
> stopped using 68000 assembler, and I haven't used any assembler at all
> since about 1996.
> 
> So that's about 27K of assembler code, 11 years old, and I haven't use
> any form of assembler for about 7 years (though I've looked at .NET IL
> assembler a couple of times recently ;-) ).
> 
> I remember being so proud of it at the time - now it seems such a
> trivial piece of code. Certainly I can read it fine. The only problem
> is that some stuff that tweaks hardware registers uses bitmasks
> without explaining the register layout. Mostly, the code is clear
> enough that I can figure that out, but these days I'd put that extra
> comment in just to save the next reader the job of working it out or
> looking it up in the manual (if they have the manual, that is - I
> certainly don't).
> 
> Also looked at some 8086 assembler from 1993 - another college
> project, this time a simple serial-port LAN. Most of the apps code
> (IIRC we had file transfer and remote printing) was in modula 2, but I
> wrote the TSR packet queueing, sending and recieving - about 1000
> lines.
> 
> I was surprised by the difference in style - sometimes commenting
> every line, and rarely with more than a few lines between comments. I
> certainly never found 8086 assembler as intuitive as 68000, but even
> so the commenting seems a bit over the top. With the
> typical-of-assembler formatting into columns, the comments don't get
> in the way however. Once again, it is perfectly readable - at least to
> me.
> 
> Basically, I think that fits my usual experience. I don't remember the
> last time I had a problem reading my own code, whatever language it
> was written in and however long since I last looked at it.
> 
> Reading other peoples code, of course, is a very different thing - but
> once again it has more to do with the programmer(s) than the language
> IMO. Python certainly makes it easy to write easy-to-read code, where
> some languages make it much harder, but some programmers just love to
> write cryptic code. Some C programmers even seem to treat the winners
> of the obfuscated C contest as some kind of style guide :-(
> 
> 
> -- 
> Steve Horne
> 
> steve at ninereeds dot fsnet dot co dot uk

I agree it is more the programmer than the language.  Specifically, I
think it correlates to the programmer's facility with
rewriting-for-clarity in any medium (e.g., writing prose).

Still, having saved a great deal of code over many years and several
languages (BASIC, C, C++, COBOL, FORTRAN, Lisp, Modula-2, Modula-3,
Pascal, Perl, Prolog, Python), I find that language does matter.  For
me, Modula-3 is the clearest for datatypes and bit-twiddling
algorithms, and python is the clearest for general-purpose and
"computer science" algorithms.  Despite my best efforts, my own perl
code is hard to pick up years later.  It is the syntax itself that
throws me off -- I can't remember the squiggles mean.

As for readability of others' code in teaming or XP settings: If the
other tema members are good at readability, then we will clash on
conventions and maybe agree to disagree in places, but will also learn
from each others idioms during code reviews.  So for a full team, we
will rapidly grow toward pretty clean code.

But when a team member is clueless about readability, you have to do
some mentoring.  I work one-on-one (basically XP without the time
pressure), and we gradually refactor, improve naming conventions, and
add comments and white space.  Each editing transform is understood
and accepted.  Eventually we get it clean enough that we can see the
"forest for the trees", and maybe select better algorithms.  Along
about then, the mentee admits the code is getting better.

After getting to clean code, we discuss the process we've just used.
I point out that this can and should be done as the program grows, not
just done as a last minute cleanup.  One such exercise does not make
massive improvements in the mentee's style, but several, plus peer
code reviews can get results.

Note: I've sometimes found that people who write unreadable code say
they don't want to change anything because it might break (as if they
had just been lucky to get it to work at all).  But after cleanup,
they admit that they actually understand the code and why it works.



-- 
harry.g.george at boeing.com
6-6M31 Knowledge Management
Phone: (425) 342-5601