Rules of Programming
Chuck Henrich
The RULES of programming
1. Make sure all functions are *completely* independant of other code
for all purposes, especially error checking! Dont expect good input.
2. Make sure code is *always* clean, and easy to read.
3. Heavily document all pieces of code!
4. Fix broken code cleanly, DO NOT hack it!!
5. Test every piece of code, before implementing new code.
6. Desk-check code at least three times after you think your completely done.
7. Test your code on at least two different machines/OS's.
8. Plan programs on PAPER before coding them.
9. Code programs on PAPER before touching the computer.
-Charles Henrich
--
__ Only Amiga! __
Charles Henrich /// /// Need a easy to use unix
Michigan State Univ __/// Above 640k Things __/// text editor? CE May be
hen...@crs.cl.msu.edu \\\/ begin to happen.. \\\/ your answer send me email
William J. Coldwell (Pres)
> The RULES of programming
> 1. Make sure all functions are *completely* independant of other code
> for all purposes, especially error checking! Dont expect good input.
> 2. Make sure code is *always* clean, and easy to read.
> 3. Heavily document all pieces of code!
> 4. Fix broken code cleanly, DO NOT hack it!!
> 5. Test every piece of code, before implementing new code.
> 6. Desk-check code at least three times after you think your completely done.
> 7. Test your code on at least two different machines/OS's.
> 8. Plan programs on PAPER before coding them.
> 9. Code programs on PAPER before touching the computer.
Is this available printed on toilet paper? ;-) ;-) ;-)
> Charles Henrich /// /// Need a easy to use unix
> hen...@crs.cl.msu.edu \\\/ begin to happen.. \\\/ your answer send me email
--
William J. Coldwell Cryogenic Software ...!m2xenix!cryo!billc
"Amiga Attitude Adjuster" Professional Programming Portal: Cryogenic
Senior Soft/Firmware Engineer Voice/Fax: (503)254-8147 CryoCafe: 503/257-4823
'I have a very large and loud mouth. It speaks for me.' Make mine a Magnum.
Juergen Weinelt
>
>The RULES of programming
>
>
>8. Plan programs on PAPER before coding them.
>
>9. Code programs on PAPER before touching the computer.
>
You must be joking! Rules 1..7 are fine with me, but 8+9 sounds like
stone age :-< (By the way, I'm a Modula-2 programmer, and I think my
programs are sufficiently clean and readable)
--
(.....this mail will self-destruct in 30 seconds.....)
----------------+-------------------------------------------------------------
o _ | Juergen Weinelt, Zur Kanzel 1, 8783 Hammelburg, Germany
| (_) \/\/ | UUCP: {uunet|rutgers}!cbmvax!cbmehq!cbmger!imart!hcast!jow
' |
Diplomacy: the art of saying "nice doggy" until you can find a rock...
Michael Franke
>>The RULES of programming
>>
>[rules 1..7 deleted]
>>
>>8. Plan programs on PAPER before coding them.
>>
>>9. Code programs on PAPER before touching the computer.
>>
>
>You must be joking! Rules 1..7 are fine with me, but 8+9 sounds like
>stone age :-< (By the way, I'm a Modula-2 programmer, and I think my
>programs are sufficiently clean and readable)
>
>(.....this mail will self-destruct in 30 seconds.....)
Unfortunately it did not self-destruct....
Have you ever been working on a larger project ? A program has to be very
thought out and partially pre-programmed in any kind of algorithmic language
like:
while the sun doesn't shine
try to read a dataset
interpret it
draw funny lines using your data
end while.
A program needs abstract data types, modularization and clever thought out
interfaces - larger projects are rarely done alone. Modula2 supports all of
the above in a very nice way. I did mid-long projects in Modula2 in a team
and it was quite good planned and we finished and (in earlier times) I did
mid-long projects starting by calling up memacs - they never finished.
greetings,
Mike
_____________________________________________________________________
/ /
/ We're here to give you a computer, not a religion. /
/ -- attributed to Bob Pariseau, at the introduction of the Amiga /
/ ------------------------------------ /
/ Michael Franke (fra...@opal.cs.tu-berlin.de) /
(____________________________________________________________________/
Jeff Dickson
>In article <1992Jan19.1...@msuinfo.cl.msu.edu> hen...@crs.cl.msu.edu (Chuck Henrich) writes:
>>
>>The RULES of programming
>>
>[rules 1..7 deleted]
>>
>>8. Plan programs on PAPER before coding them.
>>
>>9. Code programs on PAPER before touching the computer.
>>
>
>You must be joking! Rules 1..7 are fine with me, but 8+9 sounds like
>stone age :-< (By the way, I'm a Modula-2 programmer, and I think my
>programs are sufficiently clean and readable)
I have to side with this person. I'm a C and assembly programmer and
my creative juices flow the greatest when I skip 8 + 9.
Mike (My Watch Has Windows) Meyer
>>8. Plan programs on PAPER before coding them.
>>
>>9. Code programs on PAPER before touching the computer.
>>
>
>You must be joking! Rules 1..7 are fine with me, but 8+9 sounds like
>stone age :-< (By the way, I'm a Modula-2 programmer, and I think my
>programs are sufficiently clean and readable)
Have you ever been working on a larger project ? A program has to be very
thought out and partially pre-programmed in any kind of algorithmic language
like:
while the sun doesn't shine
try to read a dataset
interpret it
draw funny lines using your data
end while.
A program needs abstract data types, modularization and clever thought out
interfaces - larger projects are rarely done alone. Modula2 supports all of
the above in a very nice way. I did mid-long projects in Modula2 in a team
and it was quite good planned and we finished and (in earlier times) I did
mid-long projects starting by calling up memacs - they never finished.
What this means is that you need to plan the project. Why restrict
yourself to PAPER for that? I compose text (of any kind) much faster
with a keyboard than with a stick, and the chance of not being able to
read it later is much faster. It's also easier to share with other
members of the project, change, and generate nice output from (ever
tried typesetting notebook paper :-). Bottom line question: what other
documents do you do a rough draft on paper for if you can do it in a
WP?
I'll leave coding on paper to someone else.
<mike
--
ICUROK2C, ICUROK2. Mike Meyer
ICUROK2C, ICWR2. m...@pa.dec.com
URAQT, I WANT U2. decwrl!mwm
OO2EZ, I WANT U2.
Thaddeus P. Floryan
|>
|>The RULES of programming
|>
|[rules 1..7 deleted]
|>
|>8. Plan programs on PAPER before coding them.
|>
|>9. Code programs on PAPER before touching the computer.
|>
|
|You must be joking! Rules 1..7 are fine with me, but 8+9 sounds like
|stone age :-<
Yep. Rock-solid and non-GURUing. Anything less is simply non-professional.
|... (By the way, I'm a Modula-2 programmer, and I think my
|programs are sufficiently clean and readable)
If a colleague hasn't done a structured walk-through of your code, then your
opinion of your code is about as valuable as the paper on which this posting
is written. :-)
By the way, looks like YOU are in the stone-age. Haven't you heard yet of
Modula-3?
Thad Floryan [ th...@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
Thaddeus P. Floryan
|>[...]
|>You must be joking! Rules 1..7 are fine with me, but 8+9 sounds like
|>stone age :-< (By the way, I'm a Modula-2 programmer, and I think my
|>programs are sufficiently clean and readable)
|
| I have to side with this person. I'm a C and assembly programmer and
|my creative juices flow the greatest when I skip 8 + 9.
Sigh. Coming from a "jpl.nasa.gov" address yet. Is this why the US Space
Program is so f*cked up?
Though it's been 20 years since I've seen it, YOU are still at JPL, so I'd
suggest you look in JPL's archives for some JPL-funded research contracts
awarded to my company regarding JPL's software efforts and proving the tenets
of structured software design, implementation and quality assurance.
READ the reports, SEE the software and other results, and then let's see if
you dare make that statement in public again (unless, of course, you're just
writing arcade-style shoot-'em-up games whose software reliabilty (or lack
thereof) is non-critical or non-life-threatening).
Note the lack of "smileys".
Attitudes equivalent to the one you expressed are the type responsible for the
loss of life on one space mission (which never left the ground).
Sheesh.
Jeff Dickson
>In article <1992Jan23....@jato.jpl.nasa.gov> jdic...@jato.jpl.nasa.gov (Jeff Dickson) writes:
>|>[...]
>|>You must be joking! Rules 1..7 are fine with me, but 8+9 sounds like
>|>stone age :-< (By the way, I'm a Modula-2 programmer, and I think my
>|>programs are sufficiently clean and readable)
>|
>| I have to side with this person. I'm a C and assembly programmer and
>|my creative juices flow the greatest when I skip 8 + 9.
>
>Sigh. Coming from a "jpl.nasa.gov" address yet. Is this why the US Space
>Program is so f*cked up?
I resent that. Perhaps the U.S. Space Program is f*cked up, because
an engineer at Morton Thiocal, for example, could be repremanded by his sup-
eriors for bringing light to a potential problem. I'm speaking of course of
the shuttle accident in which seven crew members were killed.
A number of different persons have already sided with me on this
issue. You disagree and decided to throw this shit in my face, because you
couldn't come up with anything better.
The U.S. Space Program is the collective effort of thousands of
people. I don't write space craft software, but then since you stereotyped
it and me what's the difference - right?
>writing arcade-style shoot-'em-up games whose software reliabilty (or lack
>thereof) is non-critical or non-life-threatening).
On the contrary. My software designs are not without adequate planning.
I just don't follow the "rules" to a tee. I maybe bother with pencil and paper
to realize an idea graphically. Everything else is performed on the computer.
I write AmigaDOS and Exec programs. I haven't written any games, don't plan
to, and rarely play them.
Dare? You bet.
jeff
Jean-Michel Forgeas
> A program needs abstract data types, modularization and clever thought out
> interfaces [...] I did
> mid-long projects starting by calling up memacs - they never finished.
Modularization could perhaps be easier if you used an editor able to
open as many windows as you need to work. I mean real windows and not
only one window to split.
Since I work with a 'multi-windows' editor, I could not come back to a
'one-window' editor to work on a 'modularized' project.
(For thoses who are preparing their finger to hit the 'follow-up' key:
I know that a lot of very good programmers use memacs or so and they
are fast and all... But I worked with an editor like this before and
I just suggest to try a 'multi-windows' editor if you never did)
With this type of editors, the windows become as easy to use as paper,
so where is the problem in not writing on paper first?
Best regards
Jean-Michel
--
Jean-Michel Forgeas
cbmvax!cbmehq!cbmfra!swinjm!forgeas
Juergen Weinelt
>interfaces - larger projects are rarely done alone. Modula2 supports all of
>the above in a very nice way. I did mid-long projects in Modula2 in a team
>and it was quite good planned and we finished and (in earlier times) I did
>mid-long projects starting by calling up memacs - they never finished.
Just to get some things straight:
- I never intended to contradict rules 1..7 (I'm not *THAT* ignorant :-)
- what I do not like about rules 8 and 9 is that one's required to do that
kind of thing _ON_PAPER_!!! Calling up memacs (BTW, I'm using DME, thanks
Matt) with the firm intention not to create source code, but to create
meta statements instead should be sufficient as well (and *IS* sufficient
IMHO). I just do not want to use paper for this, that's what computers
are made for!
- structured software design *IS* important, but creating any
pre-implementation design studies _ON_PAPER_ certainly looks like a
stone age method to me.
bye,
Juergen
>greetings,
> Mike
>
--
(.....THIS mail will NOT self-destruct in 30 seconds.....:-)))))
Christopher Oliver
|>
|> The RULES of programming
|> 9. Code programs on PAPER before touching the computer.
|>
While rules #1 through #8 are excellent advice even for quick jobs, step
nine seems absurd in the face of a project of any size, i.e. eighty or more
pages of code per programmer. To be sure, I use paper to plan the data
structures and algorithms. A well thought out project implies a good analysis.
Nevertheless, speaking as a fellow whose penmanship, despite continued
practice, deteriorates rapidly with speed, the only way to practically
compose code is at the keyboard. If I detail my pseudocode adequately,
then coding directly from it is a routine exercise. On the other hand,
if I were to jump from fuzzy ideas directly to coding, I'd hit the wall of
obscurity pronto.
--
Christopher Oliver Computer Science Office
Concurrent Computations Research Center Friedmann Hall
Internet: oli...@cs.wmich.edu Western Michigan University
Kalamazoo, Michigan, 49008-5021
David Gay
Modularization could perhaps be easier if you used an editor able to
open as many windows as you need to work. I mean real windows and not
only one window to split.
Since I work with a 'multi-windows' editor, I could not come back to a
'one-window' editor to work on a 'modularized' project.
(For thoses who are preparing their finger to hit the 'follow-up' key:
I know that a lot of very good programmers use memacs or so and they
are fast and all... But I worked with an editor like this before and
I just suggest to try a 'multi-windows' editor if you never did)
Conversely, I find that a good editor with memacs style windows (GNU Emacs,
of course (*)) is easier to use than a 'multi-windows' editor, especially
when one has a dozen files open. It is far easier to switch to the desired
file.
To return to the original point, I feel that complex programs should be
planned on paper, but that coding is best done directly in an editor.
David Gay
ga...@disuns2.epfl.ch
*: I have modified GNU Emacs v1.10 (by Mark Henning (sp?)) to include numerous
improvements: clipboard support, menus, runs in a window, greatly improved
redisplay time (but still too slow on a 68000 alas), AREXX, dumping (loads
in 7 seconds instead of 30), etc. However it still needs more testing as it
only works on my Amiga currently ...
Juergen Weinelt
[paper purist stuff deleted :-)] <-- note the smiley, please
C'mon, I didn't say "quick and dirty". I just objected to the use of
_PAPER_. You can do just the same with your computer, it's just a
question of self control. And of course there are lots of great
tools(*) for this (if you can afford them- unlike me :-((( )
(*) before you ask: I *KNOW* there are such tools. No, I had no opportunity
of using them myself. No, I know of no such tools for the Amiga.
--
Bye,
Juergen
----------------+-------------------------------------------------------------
o _ | Juergen Weinelt, Zur Kanzel 1, 8783 Hammelburg, Germany
| (_) \/\/ | UUCP: {uunet|rutgers}!cbmvax!cbmehq!cbmger!imart!hcast!jow
' |
Think of it as evolution in action. (Niven/Pournelle, "Oath of Fealty")
Mike Schwartz
>
>[paper purist stuff deleted :-)] <-- note the smiley, please
>
>C'mon, I didn't say "quick and dirty". I just objected to the use of
>_PAPER_. You can do just the same with your computer, it's just a
>question of self control. And of course there are lots of great
>tools(*) for this (if you can afford them- unlike me :-((( )
>
>(*) before you ask: I *KNOW* there are such tools. No, I had no opportunity
> of using them myself. No, I know of no such tools for the Amiga.
My $.02:
There are some people who use computers in a creative/artistic way,
and others that use them in a scientific/academic way. Those who rely on
the scientific methods don't get the same kinds of results as those who
use the artistic methods.
Some of the best (and bulletproof) programs have been done with little
design/planning on paper ahead of time. Some of the most artistic and creative
applications are specifically designed on paper well ahead of time.
What Thad Floryan seems to be writing about is the quality control/assurance
applied to software. If a program is "crafted" in the artistic sense, there isn't
as much of a way to prove the correctness of the program. If a program is well
planned out on paper ahead of time, and changes to the plan rigorously checked
and the plan revised, the program is much easier to prove correct. It is difficult
any other way to perform this proof because of the many n-way orderings that routines
can be called.
And specifically, in the case of someone who works on applications that are
required to be crash-proof (such as space shuttle software, banking software, telephone
system software, etc.), the tiniest bug can be fatal or cost millions of dollars.
I personally use paper quite a bit, myself, but not in the traditional sense
(what's traditional about me anyhow? :) I tend to use visual tools like DPaint, my
text editor, word processor, etc., to minimize the amount of scraps of paper I would
normally end up with. But every project I do I have a ring binder full of notes that
I have kept on every single problem I ever saw with my software as well as specific
algorithm and program module designs.
Having imagry, diagrams, etc., in DPaint allows me to integrate them into
the two or three main design documents I have to do at project start time. I also
can easily bring them up on the screen to look at during the coding phase. I also
have the ability to cut text from the design documents and include them in the source
code as comments. It also allows the several people who monitor my work to maintain
a handle on my progress.
Without these kinds of things, a project that takes a few weeks tends to
grind to a halt at some point, due to lack of direction...
On the other hand, there are dozens of smaller programs that I write that
take less than a week to code up (many typically one day or less) where I don't
bother to spec the whole thing out - it makes building many small programs too
tedious a thing to do. And the scope of these programs is so small that I could
care less if I were to lose the source or forget how I figured stuff out for one.
I'd just take another day and implement a newer/better version anyhow. Code can
get old and stale :)
One last point. If software portability is the ultimate goal, then you
have to spend/waste the extra time required to ensure your software's portability.
It is too much to keep track of all the rules in your head. But once down on paper,
you can research the things you can't remember all at once.
--
Mike Schwartz
Los Altos, CA 94024
ames!zorch!amiga0!mykes or my...@amiga0.sf-bay.org
Christian Murphy
I disagree strongly with anyone who says that paper can be replaced by
computers for designing projects. Compare the two:
Display:
Computer:
- maybe 1000x1000 pixels, fairly small pixels
- strains your eyes, especially under flourescent lighting
(this applies to the DECstation I'm using here as much
as to the Amiga at home)
- number of windows/screens limited by memory
Paper:
- as much resolution as you want (well more than any computer screen)
- no eyestrain
- as many pages as you want - hundreds or thousands if need be
Ease of use:
Computer:
- varies a *lot*. You never get 100% familiar with any of the
editors, paint programs, drawing packages,etc.
- you are constrained by whatever software you use provides (you
can't lay things out the way you want to)
- speed is limited by typing, use of mouse
Paper:
- everyone is at ease with paper
- no constraints. You can mix writing, diagrams, doodles,
equations, etc
- speed is not a problem. No need to swap between mouse, keyboard,
screen, etc
Fault resistance:
Computer:
- need a clean supply of electricty
Paper:
- no need for electricity
- can tolerate spills of coffee, being dropped from a height,
being stood on and other abuse
Portability:
paper is nearly always to hand. The write-it-on-a-napkin-or-
the-back-of-an-envelope solution is a cliche.
I find computers to be a distraction when I'm trying to do some "creative",
problem-solving type thinking. Many's the time I've solved a bug or design
problem while walking home, eating meals, etc. Even when seated at a
computer, I would prefer to check any idea which seems at all difficult
on paper first.
All just my opinion of course..
>Jean-Michel Forgeas
>cbmvax!cbmehq!cbmfra!swinjm!forgeas
--
----------------------------------------------------------------------------
Christian Murphy, Trinty College, Dublin, Ireland cpmu...@vax1.tcd.ie
cpmurphy%vax1....@pucc.princeton.edu ..uunet!mcsun!ukc!tcdcs!vax1!cpmurphy
David Andreas Sjoeen
<stuff deleted>
> Portability:
> paper is nearly always to hand. The write-it-on-a-napkin-or-
> the-back-of-an-envelope solution is a cliche.
Strange... Personally, I almost never find anything to write on when I
need it, and if I find some paper, sure, the pen is gone... :-)
--
.-----------------------------------------------------.------------------.
| // | David A. Sjoen |
| -={ David }=- \X/ Amiga - it's just common sense... | Gulaksveien 4 |
| | N-4017 STAVANGER |
| E-MAIL: dav...@ifi.hsr.no (Rogaland Univ. Centre) | NORWAY |
`-----------------------------------------------------'------------------'
Matthew Dillon
possible networking configurations and run the algorithm on them in my
head), but as far as actually trying to write the PROGRAM on paper...
To put it nicely -- !!you have got to be out of your mind!! It may be
O.K. for a large corporation with a hundred programmers, assuming they
have the money to waste in lost productivity, but the result is similar
to having to walk through molasses.
As far as flow diagrams go, if you can't construct at least a general
program flow diagram in your head you shouldn't be programming, and if
you CAN construct it in your head you certainly do NOT need to write it
down! Now, a state diagram is different -- I do in fact write state
diagrams (little cicles with lines and labels) for certain
applications, such as networking protocols. I'll spend maybe an hour
or two doing that out of a 100 hour project and generally throw the
paper away once I've got the preliminaries of the program working
(because unless I were to spend another 200 hours updating the diagram
as I go it would be out of date within a week, and spending that much
time on flow diagrams instead of testing/simulation is stupid). It's
more efficient to update a text file containing a description of the
state protocol.
And any non-managorial type can tell you that all that crap doesn't do
a damn thing when it comes to finding and fixing problems -- in either
code or in the overal algorithmic design, you just get pretty pictures
that seem to make everything look ok :-) -- only simulation is able to
accomplish real program certification. One reason why the Space
Shuttle is running decade old software on obsolete computers is because
they are able to simulate 100% of the shuttle flight and it would take
years to rewrite that simulator.
-Matt
--
Matthew Dillon dil...@Overload.Berkeley.CA.US
891 Regal Rd. uunet.uu.net!overload!dillon
Berkeley, Ca. 94708
USA
Kurt Guntheroth
>>>
>>[rules 1..7 deleted]
>>>
>>>8. Plan programs on PAPER before coding them.
>>>
>>>9. Code programs on PAPER before touching the computer.
I have to add my voice in favor of rules 8 and 9. Sure, on some little
screen hack you can ignore them, and I think if you had a sufficiently good
program with text and graphics you could eliminate the physical paper in
favor of virtual paper, but the point that programs should be planned before
coding is valid.
Letting your creative juices flow straight into code results in a lot of
code in a hurry, and your program rewards you by starting to work right
away. But doing some planning and analysis up front will reward you by
letting you finish in fewer total hours. You will have a less frustrating
time getting those advanced features to work, and will have a result that
continues to work on the next OS version and the next CPU.
I think rules 8 and 9 are appropriate when building a tool or any program
that will be used by someone else. They are inappropriate when you build a
program for yourself, with no other purpose in mind than to spend some time
solving the puzzle that a great screen hack or mod represents.
Some of my more successful programs were almost fully coded before I
attempted to compile them. I find it difficult to discipline myself to work
in this way; I need the instant gratification of a successful compile and
run. But I know it is an effective method. That is why I recommend it. If
you can train yourself to work in this way, you will produce better results
faster. But it is a discipline, and not necessarily fun.
Peter Kittel GERMANY
>
> Personally, I may do an *OUTLINE* on paper (like draw pictures of
> possible networking configurations and run the algorithm on them in my
> head), but as far as actually trying to write the PROGRAM on paper...
This is exactly like I see it.
> As far as flow diagrams go, if you can't construct at least a general
> program flow diagram in your head you shouldn't be programming, and if
> you CAN construct it in your head you certainly do NOT need to write it
> down!
Exactly. When I plan a new program, I do not really start typing anything in,
until I don't have the overall structure of it clear in my head. When I got
the clue there, then it cannot go wrong any more.
Where I need paper, are logically complex details, like Matt tells with his
state diagrams. Also when I gather a lot of features I want to include,
I better write down this list to not forget one item among a dozen of
others. Or some (data file) structures are better planned (and referred to)
on paper.
But the most important thing is indeed, that I have to have a complete idea
of the thing in my head, before I can start practical work on it.
But then, I'm only a hobby programmer...
--
Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions...
Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
Mike (My Watch Has Windows) Meyer
program flow diagram in your head you shouldn't be programming, and if
you CAN construct it in your head you certainly do NOT need to write it
down!
Just because you can construct the flow diagram doesn't mean you
shouldn't write it down. Just because you can quickly build the
diagram now (when everything is fresh in your head) doesn't mean it'll
be quick in six months or more.
Now, a state diagram is different -- I do in fact write state
diagrams (little cicles with lines and labels) for certain
applications, such as networking protocols.
I do that - then turn those into comments in the code.
And any non-managorial type can tell you that all that crap doesn't do
a damn thing when it comes to finding and fixing problems
Kernighan and Plaugher cover this in "The Elements of Programming
Style." They only documentation for what a program *does* is the
actual program (and some people go so far as to recomend 2-column
coding: one for code, and one for comments, just so you can cover the
comments while reading the code), and that's what you have to fix if
it's broken.
Personally, paper vs. computer seems like a silly point to me. Those
two things are *tools* for dealing with text and graphic images. They
aren't fundamental to any programming methodology I've encountered (is
there one? Someone want to provide pointers?). You can get the same
process and documentation even if you use different tools. Sort of
like using a blue pen vs. using a black one, or using DME vs. using
TTX.
Now, there are some who feel that longer turnarounds in the
development cycle is good, because it makes programmers take more care
in fixing bugs, and not stop at one bug, and etc. Is that what is
being applied in this case?
<mike
--
The Sword of Damocles is hanging over my head Mike Meyer
And I've got a feeling someone's gonna be cuttin' the thread decwrl!mwm
Oh -- woe is me, My life is a misery m...@pa.dec.com
And all I can see is I'm on the start of a pretty big downer
John Bickers
> Exactly. When I plan a new program, I do not really start typing anything in,
> until I don't have the overall structure of it clear in my head. When I got
> But then, I'm only a hobby programmer...
Same thing for me at work, and that's banking software which is fairly
value critical.
> Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions...
--
*** John Bickers, TAP, NZAmigaUG. jbic...@templar.actrix.gen.nz ***
*** "Radioactivity - It's in the air, for you and me" - Kraftwerk ***
Greg Harvey
>Personally, paper vs. computer seems like a silly point to me. Those
>two things are *tools* for dealing with text and graphic images. They
>aren't fundamental to any programming methodology I've encountered (is
>there one? Someone want to provide pointers?). You can get the same
>process and documentation even if you use different tools. Sort of
>like using a blue pen vs. using a black one, or using DME vs. using
>TTX.
A more meaningful comparison may be that between writing code using
a `clean room' approach vs. writing code on a computer and using the
compiler as a syntax checker. I have read a study done by or for
Goddard SFC that explored these issues, and the conclusion was that
clean room approaches consistently resulted in higher quality code.
Specifically, in this approach, programmers prepare the code but
are not allowed to compile it. They run through the structured
walkthrough with the programming team and members of the compile
team. After the code has been thoroughly reviewed, THEN the compile
team compiles the code. I don't believe a distinction was made
in this study between coding first on paper or using a text
editor on the computer. I will try to find and post the
reference (<sigh> time to sludge through lots of stuff again.)
> <mike
--
Greg Harvey Lockheed Engineering & Sciences Company
Internet(yucky path): <@aio.jsc.nasa.gov:gwha...@lescsse.jsc.nasa.gov>
Houston, Texas +1 713 283 5188
Juergen Weinelt
>Personally, paper vs. computer seems like a silly point to me. Those
>two things are *tools* for dealing with text and graphic images.
I'm trying to phrase this carefully, I don't intend to start the
whole thing all over again: some people think planning programs/projects
on paper is faster (or, at least, it's safer, so you can easily afford
losing some time because you'll get it back later), others (like me) think
that paper is unneccessary today and could/should be replaced by appropriate
software tools for reasons of speed and efficiency. I wouldn't call that
a silly point, although it seems to be a matter of personal preferences.
>The Sword of Damocles is hanging over my head Mike Meyer
>And I've got a feeling someone's gonna be cuttin' the thread decwrl!mwm
>Oh -- woe is me, My life is a misery m...@pa.dec.com
>And all I can see is I'm on the start of a pretty big downer
^^^^^^^^^^^ Great movie :-)
"And crawling on the planet's face
Some insects, called the human race
Lost in time
And lost in space
And meaning"
--
Juergen
----------------+-------------------------------------------------------------
o _ | Juergen Weinelt, Zur Kanzel 1, 8783 Hammelburg, Germany
| (_) \/\/ | UUCP: {uunet|rutgers}!cbmvax!cbmehq!cbmger!imart!hcast!jow
' |
Think of it as evolution in action. (Niven/Pournelle, "Oath of Fealty")
Petra Zeidler
my $.02 worth:
I also code for other users than myself. So I want to have the _specs_ of
the program down to the last tiny detail on paper.
If the stuff is time-critical I'll look into fast algorithms first,
and use lots of paper to squish the last msec out.
That includes state diagrams, like Matt Dillon mentioned, and other
data connectivity tables (eg for a Sande-Tukey radix 8 fft).
If I do something complex I might doodle some data mapping diagrams
to get my pointers straight, and I'd love to attach some of the doodles
to my source code as comment, but that's about all I use paper for.
I just wonder how good the advocates of coding to paper are at typing;
if it distracted them considerably that would explain why they preferred
to do the writing twice.
regards,
spz
--
spz is S.Petra Zeidler | IRC: stargazer
s...@specklec.mpifr-bonn.mpg.de |
MPI fuer Radioastronomie Bonn | coming to you soon:
Auf dem Huegel 69, Germany | the home-testing kit for .sig-virus infection