Luis Moreira wrote:
> You are right, this is probably what I need.
> I never realised how difficult it was to get a relationship diagram in C
> that gives you all the information about the function interaction. But
> maybe is the way I am writing my programs.
> I started out by having a separate file for each function that I deemed
> it was large enough or had some possibility of reuse, but then it seem
> to make more sense to have library C file that had all the functions in
> it. Like this I just include one file and all the functions are there.
> At this point it doesn't seem like a good idea anymore.

Luis, I think it's great that you recognize that there is a problem and that 
you are looking for a better way.

I think that any serious procedural programmer sooner or later gets to a 
point where his program get so complex that it's impossible to grasp in its 
entirety. The natural reaction is to try to rein in this complexity with 
documentation in the form of flowcharts, interface specifications, and 
comments inside the code. I know because I've been there. It is frustrating.

About a year and a half ago, I got really tired of using the brute force 
method of learning from my mistakes, and started researching better ways of 
writing and managing code.  I read books on OOP, design patterns and 
refactoring, came across a great article on the internet written by someone 
who explained how to use C++ concepts in plain C, and bounced ideas off the 
PICList. If you were bored enough, you could follow my posts starting around 
that time, and see how the method gradually took shape.

My biggest realization was that in order to effectively manage complexity, 
one has to start thinking in terms of objects. An object is "something with 
responsibilities". It takes some practice, but eventually the answer to the 
question "where do I put this function?" becomes self-evident. Perhaps even 
more important, this works in reverse as well: you know which object a 
function resides in.

Thinking in objects has other positive side effects, for instance you get 
code that is more cohesive and loosely coupled, which in turn makes it 
reusable. If you want to give it a shot, I can describe the specifics in 
more detail.

You don't have to spend a lot of time to change over to this system, either. 
You can do it in small steps, refactoring your existing code little by 
little. So the risk is minimal, and the benefits are great.

Vitaliy


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist