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

On Sun, 10 Aug 2003 21:37:58 GMT, Roger Halstead
wrote:

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.

NS diagrams ("structured flowcharts") never added anything to
structured code. For that matter, neither did conventional flow
charts. They may have had a use once before we settled on the control
structures in use today. IMHO, there's still a pedagogical use for
conventional flow charts to teach the student how the structures work
(i.e. that the condition in a while loop is only evaluated at the
beginning of each iteration).

IMHO, there's no substitute for good naming conventions and comments
that say *why* you're doing something. I can see what you're doing.
Best ever example is the Edison Design Group source code (compiler
front ends). They've turned it into an art form.

In general, reading good code really does help you a better programmer,
almost, but not completely, exactly unlike how talking about flying
makes you a better pilot.


Can we talk about aviation now?


Morris

"G.R. Patterson III" wrote in message
...


Roger Halstead wrote:

OTOH you will
never get some programmers to use structured programming with pretty
printing and internal documentation.

We used 100% code reviews by "peers" at my former employer. Those who
didn't
use structured programming didn't stay long.

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.

I've seen plenty of C programmers crank out 30KLOC of garbage that had to be
throw away.


Since my former employer was not in the habit of handing the same
assignment
to several programmers, this never happened. Number of lines of code was
not a factor in evaluation; what mattered was whether you had completed
assignments on time, the perceived complexity of those assignments, and
the number of bugs turned up in testing.

Unfortunately for the IT field, KLOCs typically WERE the main point for
evaluation, particualrly by non-technical magagement.

Both the number of lines of code
*and* the number of comment lines *were* recorded, however.

Sad to say, non-objective measures have become the bean-counters standard
for measurement.