Text 14, 78 rader
Skriven 2004-07-27 12:16:26 av Kurt Kuzba (1:261/38)
Ärende: [C] Code File Structure
===============================
From: "Kurt Kuzba" <kkuzba@centurytel.net>


From: Bruce Partridge

BP>  I'm a long time programmer, but I have only been using C
BP>  for the last couple of years.

    I've been programming since the Commodore 64 came out, but only
 took up C back in the 90's myself.

BP>  I'm interested in finding a document or book that explains
BP>  how to split modules into files.  I have done several different
BP>  things, and none of them seem perfect.

    Steve Maquire's "Writing Solid Code" is out of print, but you
 might get one second-hand somewhere.  Steve McConnell's "Code
 Complete" is still available, however, and in its second printing.

BP>  Global and local variables seem to be obvious, but where is
BP>  the "normal" place to put hardware defines.

    Best practice would be to put them where they are needed and
 nowhere else.  The code and defines should go together.  If you
 have code specific to a hardware module, then the .h file for
 that code should be included from that .c file.  If those defines
 are not needed elsewhere, then why have them there.  A code module
 should be able to be used without outside help.  Using the #ifdef or
 #ifndef preprocessor directives will allow you to avoid duplicates.

BP>  For example, I use hardware defines that only apply if I have
BP>  a certain type of temperature sensor.  A different sensor uses
BP>  different defines.  Should these be in a global hw.h file or
BP>  in the module code file.

    The defines should be specific and non-general.  Using the
 defines for the wrong sensor should not be possible.  The defines
 should not overlap, and might include some inkling of which of the
 sensors are proper for their use.

BP>  And where do you define enums that are used in several modules.
BP>  For example, I have a state machine.   Other modules sometimes
BP>  need to know the current state.  Right now I have a enum.h file
BP>  to define the enums, then a main.h with the actual variables.
BP>  Some modules need both, and some don't.

    No idea on that one.  Current thought on that, as far as I know,
 runs to encapsulation, so you would have a function which holds the
 values and returns them upon request, using a switch value.  In C++,
 you would create a class to handle it.

BP>  I also have questions about reusable code, and how to optimally
BP>  split up the files.

    Split them up how you use them.  Functions form families, like
 the printf() and scanf() families, which all fall into the stdio.h
 library module header.  If a function needs support functions, they
 belong with it.  At some point, you have to consider granularization,
 which means that your modules should be small enough that you don't
 include a lot of unnecessary stuff when you grab just a couple of
 functions in a library.  You have smaller granules of code then, and
 you suffer less bloat.

BP>  Anyway, I think it would be time well spent for me to learn
BP>  more about "best practises."

    I'm reacquainting myself with those right about now.  I just got
 done with a rewrite of my little numdrop.c program.  It's in ver4
 now, and uses no globals.  I'm going to post it right after I finish
 this, actually.

Kurt - Wisconsin, USA

>  kkuzba@centurytel.net   http://home.centurytel.net/kkuzba
>  What is rooted is easy to nourish (Tao te Ching #64)

--- BBBS/LiI v4.01 Flag-5
 * Origin: Prism's_Point (1:261/38.1)