Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There is plenty of material about designing software for object oriented programming. Do you know of any good materials for pure structural programming? I am working purely in C and while I can use some experiences from object oriented programming I found out, that I know few tricks about good structural design.

share|improve this question

closed as off-topic by gnat, GlenH7, MainMa, Ixrec, MichaelT Mar 29 '15 at 17:11

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, GlenH7, MainMa, Ixrec, Community
If this question can be reworded to fit the rules in the help center, please edit the question.

You could do, as an programming excercise, to take common classes from Java or C# that have static methods into modules with global functions. The String class is a good example. "O.O. String Class static methods" => "Structured Strings Library" – umlcat Mar 19 '11 at 19:18
up vote 1 down vote accepted

One of the best books on this is out of print, but still easy to find used (and rather cheaply): Reliable Software through Composite Design, by Glenford J Myers.

A much more expensive resource (but in print) is Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design.

Of course, the book on the C language itself is an excellent guide to programming. It doesn't talk about coupling the way Myers does, but you should definitely have K&R on your shelf. Note that many large C systems do use OO concepts, including dispatch tables to get many of the same features of polymorphism (such as extensibility).

share|improve this answer

Hard to say. Back when I was learning, the main structured programming advice was basically "use block structures" and "don't use goto", which only takes you so far.

There was a technique called "Jackson Structured Programming" in which you would describe the structure of your input and output data, and the structure of your program was derived as the in-between thing. The diagrams weren't so terribly aweful as the overall method, which was AFAIK primarily targeted at COBOL and at fairly simple data processing tasks.

In other words, the specific advice that you can find for structured programming is often advice that you shouldn't follow in the real world - overly simplistic and pedantic, based on the assumption that programmers are incapable of thinking about such "complex" ideas as repetition without a pretty picture and a heavyweight methodology to help them.

What is perhaps useful is to point out that on the whole, the "design patterns" for structured programming were algorithms and data structures, or at least that's how things seemed in the 80s and 90s before the term "design pattern" had been popularised. Current non-OO developers will have larger-scale design patterns now, of course, but as a C++ programmer myself who hasn't used much C, Pascal or whatever for over a decade, I can't comment much on that.

A few idioms are also relevant, but let's just say that your object oriented programming experience will have already given you some idea of when and how to use a "parameter block" for instance - a class is in many ways the evolution of a parameter block, and I suspect (but don't know for sure) that many C++ object-oriented patterns have near-equivalent C parameter-block patterns.

Also, some object oriented design patterns are needed to some extent to work around data hiding issues. Abstraction is good design, but sometimes having a good abstraction is hard work where having a leaky abstraction permits much simpler solutions, at least in the short term.

share|improve this answer
I add modules / namespaces or "Modular programming", sometimes is consider the same as "Structured Programming" or teached with "Structured Programming", but sometimes is not. – umlcat Mar 19 '11 at 19:05

good design in C:

  • use typedefs for data structures
  • write functions to operate on data structures
  • group functions that operate on the same data structure into modules


share|improve this answer
Downvoted: typedefs in C make the program more opaque. One never knows what the typedefed thing is -- struct, union, pointer, multiple pointer, primitive type.. – zvrba Dec 31 '10 at 16:10
Encapsulation == Opaque. – compman Dec 31 '10 at 18:56
@zvrba - seems to me that to compensate for the "struct" prefix, you've abbreviated "LARGE_INTEGER" to "li". Last time I used two-letter identifiers for something with a scope greater than a few lines, I think I was "working" in Commodore 64 Basic. "li" could mean pretty much anything. The "struct" prefix won't bother me, but I'd still want an identifier that tells me what it means. – Steve314 Jan 3 '11 at 0:24
@zvbra - OTOH, you're concern about opaqueness bothers me. Push it too far and writing functions is evil, because writing the code directly where needed instead of a call is more "transparent". I use the "moving the complexity to the call graph doesn't eliminate complexity" argument myself, but there's a balance. The typedef is more of the same - how much genuine need is there to emphasize that a particular type happens to be a struct in every reference to it? – Steve314 Jan 3 '11 at 0:30
@zvrba: at least you are actually using structs, despite the risk that a struct member could be hiding ANYTHING (pointer, integer, function pointer). ;-) – Steven A. Lowe Jan 3 '11 at 17:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.