Hi,
I do not know when it happened, it was so long ago
but all the programming
tasks I do now are first thought of in what is called
"pseudo language".
That is, I look for what is to be done and work on
approaches that may work
and then iterate and refine the ideas on how to
approach the problem.
Most often I am only concerned about sub parts of
the problem and when a
workable idea has appeared the next sub part is
examined.
When several parts have been examined I think about how the
parts can be
combined to do a larger task or function and the entire
project.
During this period there is NO programming language involved.
NONE! I am
doing a "thought exercise" only.
Only when the design has
reached a point that it may well work is a trial
implementation in some
language thought about. Still at that point that no
code will be written
except for exploring uncertain ideas and attempts to
improve the design. The
code may never actually be run, I am just trying to
confirm that something
can be done in some language.
I draw on ideas that I have used in the
past and how others have done
similar tasks.
I look at running
examples and try and extract the basic algorithm that is
being used for sub
tasks.
If you can look at some code in any language and understand what
it is doing
and how it does it you are starting to build up your personal
knowledge
base.
When all the parts appear to have workable algorithms
then you can choose a
programming language and start writing
code.
-------------------------------------
While the process was
totally informal when I was designing "Urbane", some
of the basic parts
were:
Reading lines of text from a file.
Separating those
lines into tokens.
Checking each token to see if it is a
"Keyword"
and if not, checking if it is a "Line Number",
and if not,
checking if it is a known "Variable",
and if not then it must be a "New
Variable".
During the first reading of the file, just the first tokens
which must start
in column one are collected as "Line Labels". This is a
common practice when
there are forward references which must be determined
first.
The second pass starts each output line off with a line number,
adds
keywords unchanged to the output line, inserting actual line numbers
for
line labels and replacing variables with their assigned 2 character
variable
names.
The parser is very different from the one that I
initially planned to use. I
realized that a much simpler one would do the job
so I did not write a more
traditional syntax driven one like DECB uses. This
is at the cost of much
less error checking and poor reporting. As the number
of users may be small
this is a good trade off and is based on the
requirement that only
syntactically correct DECB statements are
allowed.
Central to the processing is the concept of asking the
question:
Given the last character, what are the legal possibilities for
the next
character and then checking for each possibility. In parsing the
input line,
a unexpected character is just copied to the output and any
series of blanks
are reduced to just one blank. I was very happy as so much
code was
eliminated by just moving the unexpected character unchanged to the
output
stream.
One section of the code was giving me problems. I just
could not see how to
make it work. I realized that it was a function that
could be given a
meaningful name and after creating the function and defining
the input and
output parameters the code would work. The key was adding an
additional
parameter to be returned with a useful name. Now with a defined
interface
the special cases could be separated out and it was clear how to
use the
function and what to so with each special case upon
return.
There are several functions that remain as in line code, should I
do further
work they will be defined as naming then makes the program
operation easier
to understand.
Now, Urbane does not follow exactly
the above words. DECB programs for the
most part are intertwined jumping to
places to handle special cases.
With a different language with better
constructs, the program flow would be
easier to understand. Trying to use
these constructs in a language that does
not have the underling support may
produce even less understood programs.
Reading the code is somewhat like
reading the English like "pseudo language"
I design in. I found the "Urbane
Basic" language to be just great and I am
very happy I am doing the
project.
I hope these thoughts help. Just don't get bogged down writing
code when you
do not understand what the pieces of the project are and how
the program
will operate.
Stephen H. Fischer
Jim Cox
wrote:
> As I dive
into C programming, one of the major issues I
> have to overcome is
learning create a program in the most
> direct and simplest way possible.
I shouldn't say it's an
> issue as it is more of a skill I need to
develop.
>
> I understand this takes time and practice, but I'd
like to
> know if anyone out there has any recommendation for a
good
> book on just software design?
>
> I'm starting to read
Code Complete, but if possible I'd
> like to get more than one point of
view. Thanks.
>
> -Jim