Flight planning spreadsheet

On Sun, 10 Aug 2003 10:53:16 -0400, Andrew Gideon
wrote:

Roger Halstead wrote:

I've seen code that students turned in where it took more work to
decipher than it did to write it. Course I saw a few students who
could write Pascal that way too and it's almost a plain language when
it comes to source code.

Please help.

Shouldda had my old instructor in college. You turned in nothing with
out a flow chart (Nazzi Schinerdman?). Then pseudo code, then the
program with plenty of internal documentation.

You might have trouble understanding the code in a few months but with
the internal docs you at least knew what it was supposed to be doing.
:-))

You've the perfect opportunity to teach that code is almost universally read
more than it is written. More, the reader is typically unfamiliar with the
code being read - even if it's the author, but a few days or weeks or
months or years downstream.

When I was working as a Sysadmin, Developmental analyst, and finally
as a project manager I spent a good deal of time rewriting many of the
programs used by our Laboratory Information Management System (LIMS).

One of our people at a different site was a great programmer, except
he would just write as much stuff as he could get on each line and no
documentation. It not only made it difficult to read, but oft times
the code would behave differently. We used a Pascal "like" language
called VGL. It was easy to work with and easy to use. Dynamic memory
allocation and pointers were transparent to the programmer so you
never had to remember "new" and clear". Then again you didn't create
any linked lists.

This should motivate the writing of code designed not to be written quickly,
but read easily. Avoiding nested returns, keeping logic expressions
simple, commenting, writing short functions...

Pretty Printing.
Nested returns and logic need not be obscure. Flow charting *usually*
cures problems with nested returns and logic.

The big kicker is that like writing to make things easier for the
user, writing for readability with internal documentation takes extra
time. Time that can be saved many times over when modifying that
code later on. Unlike writing for ease of use, writing for
readability does not make the program more complicated. OTOH you will
never get some programmers to use structured programming with pretty
printing and internal documentation.

Then again, that extra time may grate on management. When they see a
programmer write code in a day that takes another two or three, they
see efficiency. They don't see the extra weeks work it takes to
decipher the quickly written stuff and modify it later on. With that
kind of code it's often easier to start from scratch.

I taught in a "new hire" program for a number of years at a couple of
investment banks in NYC a while back. Too may (most?) of the people hired
regarded the concept of writing code to be written as foreign.

I hold one stance on that, if they aren't trained programmers they
shouldn't be writing code. Programming is "grunt work" and takes a
specific mind set and dedication.

Then you get into larger programs that require team work and
coordination. (I've been a project manager where both hardware and
software were concerned as well as modifying the way a corporation had
to do their networking with FDA validation) They have to write to a
given specification so each programmers part will work with all the
others which is far different than the environment where one person
writes some small programs or routines.

It's much like filing a flight plan. It has to be properly organized
to work in the system.

Roger Halstead (K8RI EN73 & ARRL Life Member)
www.rogerhalstead.com
N833R World's oldest Debonair? (S# CD-2)


- Andrew