help: good sturdy C procedural program design

[John Gabriele]

The way I've always "designed" procedural C programs has just been to:

A. Think about what I need to do
B. Draw a flowchart with pencil and paper
C. Implement the flowchart in C from the top down
D. Compartmentaliz e chunks of code that serve some specific purpose
into functions, while filling in the framework left by the top-
down approach.
E. Refactor until I can call it pretty much done.

Though, I haven't created any large C projects myself (mostly just
programs consisting of maybe 5 to 10 source code files), so it could
be that the above process will land me in deep doo doo once my projects
start getting larger.

Any advice on procedural C program design?

Thanks.
--- if contacting via email, remove zees ---

[Malcolm]

"John Gabriele" <jo*****@bestwe bz.net> wrote in message

A. Think about what I need to do This is vitally important. B. Draw a flowchart with pencil and paper Flowcharts are really for assembly routines. For C programs they have 2
weaknesses - if a flowchart fits on a side of A4 then it is so simple that
there's not much point, whilst if it is larger it becomes unwieldy, and
there is no accepted electronic means of storing flowcharts.
C. Implement the flowchart in C from the top down
Some people will do this, so what I say is only one opinion. Generally code
should be designed top-down in a quick pass, and then written bottom up. The
reason is that you can then test as you write.
D. Compartmentaliz e chunks of code that serve some specific
purpose into functions, while filling in the framework left by the top-
down approach.
This the problem with the top-down approach. You may have a framework of
function calls, but no code to go in them. Each function should do one
specific thing which can be described simply, and ideally can be tested.
Write scratch code to test the functions as you write them. Obviously,
higher-level functions will need to call lower-level functions, so you write
the lower level functions first. Then they get tested again as you test
their callers.
E. Refactor until I can call it pretty much done.
What's this meant to mean? If you follow a rigorous bottom-up approach and
you have a complete design, then this shouldn't happen. Reality is that with
big programs you tend to have to design and build as you go. No engineer
would tolerate such an approach to building a bridge, but with software
people are always asking "just pop in a quick "undo" function". Programmers
aren't innocent either, often playing with code until something works.
Any advice on procedural C program design?

The most important relationship in programming is dependency. Once you
realise that then everything else pretty much falls into place.

[John Gabriele]

Malcolm wrote:

"John Gabriele" <jo*****@bestwe bz.net> wrote in message

A. Think about what I need to do
This is vitally important.

B. Draw a flowchart with pencil and paper

Flowcharts are really for assembly routines. For C programs they have 2
weaknesses - if a flowchart fits on a side of A4 then it is so simple that
there's not much point, whilst if it is larger it becomes unwieldy, and
there is no accepted electronic means of storing flowcharts.

C. Implement the flowchart in C from the top down

Some people will do this, so what I say is only one opinion. Generally code
should be designed top-down in a quick pass, and then written bottom up. The
reason is that you can then test as you write.

D. Compartmentaliz e chunks of code that serve some specific
purpose into functions, while filling in the framework left by the top-
down approach.

This the problem with the top-down approach. You may have a framework of
function calls, but no code to go in them. Each function should do one
specific thing which can be described simply, and ideally can be tested.
Write scratch code to test the functions as you write them. Obviously,
higher-level functions will need to call lower-level functions, so you write
the lower level functions first. Then they get tested again as you test
their callers.

E. Refactor until I can call it pretty much done.

What's this meant to mean?

I'm sorry. I should've thought more before writing that. I was thinking
of C++ where I sometimes end up with objects that need to know too much
about each other.
If you follow a rigorous bottom-up approach and
you have a complete design, then this shouldn't happen.
Right, unless/until -- as you point out -- requirements get tweaked.
Reality is that with
big programs you tend to have to design and build as you go. No engineer
would tolerate such an approach to building a bridge, but with software
people are always asking "just pop in a quick "undo" function". Programmers
aren't innocent either, often playing with code until something works.

Any advice on procedural C program design?

The most important relationship in programming is dependency. Once you
realise that then everything else pretty much falls into place.

Thanks for the insightful reply Malcolm!