Pseudo-Code (and flow-charting) 
Author Message
 Pseudo-Code (and flow-charting)

As a follow-up to the GO TO thread.

As many of the regular C.L.C. readers know, I do not currently (and it has
been MANY a year since I) make my living writing "real" production code.
Therefore, you may take this with a "grain of salt".

However, one of my favorite coding techniques (since punched cards and coding
sheets died their well deserved deaths), is to write pseudo-code to help me
analyze a "problem". (This can be either for a new program - or for a section
of code that I am required to add.  This does NOT work for doing
"maintenance" on an existing program - unless that maintenance is to add a
new "features/function".)

I then take this "nice" machine readable pseudo-code (that isn't particularly
pseudo) and "flesh it out" until I have the basic structure  (and by using
pseudo-code it usually is structured) for my procedure division.   By using
"stub" paragraphs and calls, my actual pseudo-code tends to grow from my
program "mainline" (or paragraph logic) into my actual program source code.

I am not saying that this technique would work for everyone (or that I would
*ever* require it for someone else).  Nor do the various "stages" of my
pseudo-to-non-pseudo-code ever reach "official" application documentation
status.  However, this does work for me.

--
Bill Klein
    wmklein <at> ix dot netcom dot com



Wed, 30 Oct 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Hi:

What you talk about is flowcharting in a way. It doesn't have to
be a formal flowchart using the official IBM flowcharting
template (if you can find them anymore?). Whether you call
it pseudo code or scribble something in a flowcharty way, you
are really getting a cohese idea of the Big Picture. Sitting
down and starting typing without doing that is asking for
trouble - unless, of course, you are coding something which
you have coded a thousand times before. . .

Thanks

Tony Dilworth

Quote:
> As a follow-up to the GO TO thread.

> As many of the regular C.L.C. readers know, I do not currently (and
it has
> been MANY a year since I) make my living writing "real" production
code.
> Therefore, you may take this with a "grain of salt".

> However, one of my favorite coding techniques (since punched cards
and coding
> sheets died their well deserved deaths), is to write pseudo-code to
help me
> analyze a "problem". (This can be either for a new program - or for a
section
> of code that I am required to add.  This does NOT work for doing
> "maintenance" on an existing program - unless that maintenance is to
add a
> new "features/function".)

> I then take this "nice" machine readable pseudo-code (that isn't
particularly
> pseudo) and "flesh it out" until I have the basic structure  (and by
using
> pseudo-code it usually is structured) for my procedure division.   By
using
> "stub" paragraphs and calls, my actual pseudo-code tends to grow from
my
> program "mainline" (or paragraph logic) into my actual program source
code.

> I am not saying that this technique would work for everyone (or that
I would
> *ever* require it for someone else).  Nor do the various "stages" of
my
> pseudo-to-non-pseudo-code ever reach "official" application
documentation
> status.  However, this does work for me.

> --
> Bill Klein
>     wmklein <at> ix dot netcom dot com

--
what is a signature?

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 30 Oct 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)
On Sat, 13 May 2000 11:01:51 -0500, "William M. Klein"

Quote:

>I am not saying that this technique would work for everyone (or that I would
>*ever* require it for someone else).  Nor do the various "stages" of my
>pseudo-to-non-pseudo-code ever reach "official" application documentation
>status.  However, this does work for me.

Bill,

This is largely how I write code.  "My" pseudocode is not really
formal Pseudocode, but by own -- basically english -- code.  

I place this as comments in the procedure division.  Then I code each
section of Pseudocode in COBOL, many times performing paragraphs that
don't exist or using data names not yet defined.  When I think I am
"Close" I let the compiler do the work.  I just compile and fix errors
until it works.  MOST of the time, when I get a clean compile I have a
working program.

This works today because compilers are so much faster and we are
working on largely PC's for our development.  This would not work in
the one compile a day age of yesteryear.



Thu, 31 Oct 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:
> This works today because compilers are so much faster and we are
> working on largely PC's for our development.  This would not work in
> the one compile a day age of yesteryear.

Hi:

It does work, for me too.  I like to code a few lines,
compile, and test. When it takes longer to type in the
command to compile than the compile itself why not use
this method to make rapid progress. Actually, with a macro
keyboard or DOSKEY, you can reduce compile and link
commands to a single keystroke, making the edit-compile
-test routine very fast. The majority of my programs
compile and link in less than a second and I only have
a 233mhz Pentium. How does the comparable routine work
on the mainframe?

Thanks

Tony Dilworth

Sent via Deja.com http://www.deja.com/
Before you buy.



Thu, 31 Oct 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:

>On Sat, 13 May 2000 11:01:51 -0500, "William M. Klein"

>>I am not saying that this technique would work for everyone (or that I
would
>>*ever* require it for someone else).  Nor do the various "stages" of my
>>pseudo-to-non-pseudo-code ever reach "official" application documentation
>>status.  However, this does work for me.

>Bill,

>This is largely how I write code.  "My" pseudocode is not really
>formal Pseudocode, but by own -- basically english -- code.

>I place this as comments in the procedure division.  Then I code each
>section of Pseudocode in COBOL, many times performing paragraphs that
>don't exist or using data names not yet defined.  When I think I am
>"Close" I let the compiler do the work.  I just compile and fix errors
>until it works.  MOST of the time, when I get a clean compile I have a
>working program.

>This works today because compilers are so much faster and we are
>working on largely PC's for our development.  This would not work in
>the one compile a day age of yesteryear.

Even years ago, a lot of us wrote code the same way.  We'd just end up
working all night when the machine was available.


Thu, 31 Oct 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:

>:

> What you talk about is flowcharting in a way. It doesn't have to
> be a formal flowchart using the official IBM flowcharting
> template (if you can find them anymore?). Whether you call
> it pseudo code or scribble something in a flowcharty way, you
> are really getting a cohese idea of the Big Picture.

I do all my coding by starting in pseudo-code.

It happens that this 'pseudo-code' can be understood by the compiler.

After I get the main-line 'pseudo-code' working (as demonstrated by
compile-test) I refine the pseudo-code by expanding each level until it
achieves its design goals.



Fri, 01 Nov 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:

> It does work, for me too.  I like to code a few lines,
> compile, and test. When it takes longer to type in the
> command to compile than the compile itself why not use
> this method to make rapid progress. Actually, with a macro
> keyboard or DOSKEY, you can reduce compile and link
> commands to a single keystroke, making the edit-compile
> -test routine very fast. The majority of my programs
> compile and link in less than a second and I only have
> a 233mhz Pentium. How does the comparable routine work
> on the mainframe?

If your queues are long it is absolutely awful.  A few years back I
had to wait a minimum of one hour for a compile cycle.  Not a good
idea to make a typo.  A compile cycle on Unix is seconds a job in MVS
takes a few minutes, the compile cycle cost can be high.

I have heard it said that your code should compile cleanly on first
hit because if you are concentrating this is easily achievable.  I try
and make it right first time but I am not that concerned with perfect
first time compiles.

I prefer portable source and a PC any day.

Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/



Fri, 01 Nov 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:

> Hi:

> What you talk about is flowcharting in a way. It doesn't have to
> be a formal flowchart using the official IBM flowcharting
> template (if you can find them anymore?). Whether you call
> it pseudo code or scribble something in a flowcharty way, you
> are really getting a cohese idea of the Big Picture. Sitting
> down and starting typing without doing that is asking for
> trouble - unless, of course, you are coding something which
> you have coded a thousand times before. . .

Or unless your coding style duplicates the functionality of a flow
chart.


Fri, 01 Nov 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:

> If your queues are long it is absolutely awful.  A few years back I
> had to wait a minimum of one hour for a compile cycle.  Not a good
> idea to make a typo.  A compile cycle on Unix is seconds a job in MVS
> takes a few minutes, the compile cycle cost can be high.

I remember turning the source in to be punched one day, running it
through the syntax checker the next night, and compiling it the
following night.

Now, the first thing I do is compile with a dummy procedure, just to
pull in copy members into one place.  (I still think a strength of
traditional COBOL as opposed to OO and library based languages is the
ability to get everything I need in one place)



Fri, 01 Nov 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

----------


Quote:

>> It does work, for me too.  I like to code a few lines,
>> compile, and test. When it takes longer to type in the
>> command to compile than the compile itself why not use
>> this method to make rapid progress. Actually, with a macro
>> keyboard or DOSKEY, you can reduce compile and link
>> commands to a single keystroke, making the edit-compile
>> -test routine very fast. The majority of my programs
>> compile and link in less than a second and I only have
>> a 233mhz Pentium. How does the comparable routine work
>> on the mainframe?

Anywhere from 20 seconds to 5+ minutes.  Mostly depends on the length of the
program. But our compile also runs the code through a checkout process
(ENDEVOR), an IDMS preprocessor (if necessary), a linker, and a source code
librarian.  So really, a compile is more than a compile.

Quote:

> If your queues are long it is absolutely awful.  A few years back I
> had to wait a minimum of one hour for a compile cycle.  Not a good
> idea to make a typo.  A compile cycle on Unix is seconds a job in MVS
> takes a few minutes, the compile cycle cost can be high.

> I have heard it said that your code should compile cleanly on first
> hit because if you are concentrating this is easily achievable.  I try
> and make it right first time but I am not that concerned with perfect
> first time compiles.

But doesn't it feel great when it works the first time!
Quote:

> I prefer portable source and a PC any day.

> Thanks
> Ken Foskey
> http://www.zipworld.com.au/~waratah/



Fri, 01 Nov 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:

> I remember turning the source in to be punched one day, running it
> through the syntax checker the next night, and compiling it the
> following night.

> Now, the first thing I do is compile with a dummy procedure, just to
> pull in copy members into one place.  (I still think a strength of
> traditional COBOL as opposed to OO and library based languages is the
> ability to get everything I need in one place)

The use of copy books to contain code (I am assuming this is what you
are talking about) then you negate the ability of the programs to be
partially compiled once only.  This can be done in DOS and Unix using
make (example for Fujitsu available on request) or by SCLM on IBM
mainframes (it is free by the way and stores versions).

If you program to an interface then you do not need to see the
implementation.  Cobol can be a library based language, this is where
I want to be.  Opinions differ :-}

Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/



Sat, 02 Nov 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:

> > Now, the first thing I do is compile with a dummy procedure, just to
> > pull in copy members into one place.  (I still think a strength of
> > traditional COBOL as opposed to OO and library based languages is the
> > ability to get everything I need in one place)

> The use of copy books to contain code (I am assuming this is what you
> are talking about) then you negate the ability of the programs to be
> partially compiled once only.  This can be done in DOS and Unix using
> make (example for Fujitsu available on request) or by SCLM on IBM
> mainframes (it is free by the way and stores versions).

> If you program to an interface then you do not need to see the
> implementation.  Cobol can be a library based language, this is where
> I want to be.  Opinions differ :-}

I'm not sure I follow you.  My first compile is so I can see all of the
field names, displacements, sizes, etc.  I add I/O of my own, such as
report formats.  I'm not concerned with PROCEDURE DIVISION copy members
at this time.  I am unfamiliar with the concept of partially compiled
code.


Sat, 02 Nov 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:


> > > Now, the first thing I do is compile with a dummy procedure, just
> > > to pull in copy members into one place.  (I still think a
> > > strength of traditional COBOL as opposed to OO and library based
> > > languages is the ability to get everything I need in one place)

> > The use of copy books to contain code (I am assuming this is what
> > you are talking about) then you negate the ability of the programs
> > to be partially compiled once only.  This can be done in DOS and
> > Unix using make (example for Fujitsu available on request) or by
> > SCLM on IBM mainframes (it is free by the way and stores versions).

> > If you program to an interface then you do not need to see the
> > implementation.  Cobol can be a library based language, this is
> > where I want to be.  Opinions differ :-}

> I'm not sure I follow you.  My first compile is so I can see all of
> the field names, displacements, sizes, etc.  I add I/O of my own,
> such as report formats.  I'm not concerned with PROCEDURE DIVISION
> copy members at this time.  I am unfamiliar with the concept of
> partially compiled code.

You are right, awful terminology.

'Modularized code' and each module is compiled independently (but
completely) and the final result is linked together.  So the program
is compiled partially (each module is compiled up to the link stage).
If you make a change in one module then only it is compiled (based on
date/time stamps on the files).

The concept of copying in template code using copybooks is used by
some programmers, they include procedural code in copybooks.  I even
did it myself a while back.  I have come to the opinion that this is
not 'best practice'.

I misunderstood your original note, based upon your response.  What
did you mean by library based languages?  Libraries are a great idea,
IMHO.

Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/



Sun, 03 Nov 2002 03:00:00 GMT  
 Pseudo-Code (and flow-charting)

Quote:

> I misunderstood your original note, based upon your response.  What
> did you mean by library based languages?  Libraries are a great idea,
> IMHO.

They are.  But as with any choice, there is a cost.  A library based
language (my term) is one where most of the code is not in your program
- but is in libraries instead.  Java is like this.  The amount of hidden
code which you have to know is tremendous - much more than we have with
our COBOL commands.  Theoretically, the code is all debugged, won't
change, and there is no reason for us to look at it.

Theoretically.   But I have discovered bugs in COBOL - certainly bugs in
libraries are more common.  In the case of Java, upgrades to the
language have broken existing programs which were on other people's web
pages.

I don't need to know the mechanisms of most COBOL commands (there are
exceptions - for instance I need to know how COMPUTE handles
intermediate variable's overflow).  But I believe that the amount I need
to know from library code is significantly greater than advocates
imply.  I believe that the large libraries are much harder to have a
working knowledge of.  I believe that enterprises often create new
library members even when old ones exist - because they KNOW their
members, and don't want to change existing members and test everything
they touch.  I believe that programmers don't want to depend on other
people's code - especially if it might change.

Sometimes you have to do this.  The code to create GUI objects is
complicated and dependent upon hooks to the operating system.  But
business rules are not always enterprise wide.  We create a library
member with HR's business choice and find AR is just enough different
that we cannot use that member as it is.  If we change that member, then
we have to test every program which uses it.  So we don't, we make our
own code.   If foreign code isn't used by multiple programs, then it is
just a way to make it harder to see what a program does - without the
advantages of being foreign.



Sun, 03 Nov 2002 03:00:00 GMT  
 
 [ 33 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Pseudocode to flowchart converter

2. flow-charting f77 code

3. Writing assembler code/pseudo code

4. JCL flow chart

5. Tools to Develop Flow Charts

6. FLOW CHART construction in TURBO PASCAL

7. Flow Charting Program

8. flow charting lang.

9. Programmable flow chart

10. State diag. and Flow chart design

11. Flow chart tool

12. Flow Charts

 

 
Powered by phpBB® Forum Software