Oh Christ, I'm doomed....

long island_ice_tea();

I'm bored, ok?

 

Bah. Not quite as obsessional as Perl poets' outpourings.

<http://docstore.mik.ua/orelly/perl/prog3/ch27_02.htm>

 

Heh, yes, I had souece code that used variables i, s & t throughout
once. And had few comments "because I prefer my code that way".

On the other hand, one thing that also annoys me is the attitude that
"the code is self-documenting, so doesn't need comments." This is
bollocks IMO. Self-documenting code names might tell a reader /what/ a
function's doing but not necessarily /why/ the **** it's doing it,
especially where it is being called. True that comments can fail to
get updated when the code changes, which is possibly worse still,
mind.

And don't get me started on the morons who try to cram as much code
vertically as possible: there's a reason that things like manuscripts
used to be typed double-spaced.

And while we're at it...

 

Quite so, and it's equally, if not more, fallacious, when people say
"the spec is in the program comments, I don't need a separate
document."

If I had a penny for every legacy program I've had to retro-specify...

 

A good way to drive the point home to a student is to point at their
code and ask `What does that line of code do?'

 

you'd probably have about 78 pence.

 

<recounts>

Yea, summat like that.

 

<fx: my mum>
If I've told you once, I've told you a million times not to
exaggerate.
</fx>

 

End Sub 'TFFT

--
+-------------------------------------------------------------------+
| Pete Fisher at Home: |
| Voxan Roadster Yamaha WR250Z/Supermoto "Old Gimmer's Hillclimber" |
| Gilera GFR * 2 Moto Morini 2C/375 Morini 350 "Forgotten Error" |
+-------------------------------------------------------------------+

 

Yes, but then you can get the stupid situation of code being peppered
with ridiculous comments such as:

i++; // increment

 

The trouble is that when you've just written something it's all in your
head and you can answer such a question quite easily.

Ideally you'd make them pass bits of code around between groups or make
them do maintenance work on their own code after some months doing
something else.

I think it's only when you've had to try and figure out a hairy ball of
cruft written by someone else that you really understand the importance
of documentation. I'm not sure there's enough time for students to learn
this kind of mindset.

 

Actually, they very often can't, because they haven't thought out what
they're doing *before* they start typing.

The problem I have is getting them to properly test small fragments of
code before including them in the grand design.

 

Get them to read Chapter 7 of "The Olduvai Imperative" by DeGrace and
Stahl.
--
+-------------------------------------------------------------------+
| Pete Fisher at Home: |
| Voxan Roadster Yamaha WR250Z/Supermoto "Old Gimmer's Hillclimber" |
| Gilera GFR * 2 Moto Morini 2C/375 Morini 350 "Forgotten Error" |
+-------------------------------------------------------------------+

 

Well, that sounds like a question of lack-of-design rather than
lack-of-documentation. Or is that the same thing?

I guess you've tried getting them to write psuedocode as comments first?

 

Pretty much, for the kind of coding we're talking about.

I've tried asking them to show me the equations. They often try to
implement those in their heads.

 

Yes.

Although there's a time and a place for ad-hoc or experimental
programming, of course, but the key is to recognise it for what it is
and ensure that once the programming is done, a proper specification,
or detailed description if you prefer, is created.

Any thorough QA/Validation process should confirm that a spec exists,
and that it is correct and up-to-date, before putting a new program
into production.

 

How do you create the spec? Is it out of thin air? Where is the thinking?

 

Look, if you've never done this type of programming, I'm not about to
try and explain how, but yes, it's entirely possible to make up a
program as you go along. And sometimes it can shortcut software
development quite significantly. Not _always_ good, but if it's done
with due diligence and proper post-hoc documentation, it can produce
impressive results.

http://en.wikipedia.org/wiki/Extreme_programming explains some of the
ideas.

 

Indeed. But Extreme Programming is just it's fancy post-2000 name.
I've been doing that since the early 80s when it was just known as
Making It Up As You Go Along.

 

Or perhaps more relevant:
C++; /* increment C but use the original */