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.
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).
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.
good design in C: