C Programming Estimates/Standards

[George W. Leach]

In article <186 at zeek.UUCP> larry at zeek.UUCP (Larry Podmolik) writes:
>I'm looking for information on the following 2 subjects:

>1. C programming estimates for programmers of various levels  working  on
>   programs of varying complexity.   I think this is probably harder than
>   for, say,  COBOL because knowledge of  UNIX libraries,  etc.  can make
>   such  a big difference (both in coding speed and in lines of code that
>   need to be written).  Also, debugging time can vary so widely - sloppy
>   C programs can be IMPOSSIBLE!

     Well, I can't help out much on the programming estimates part (who
honestly can?).  However, as far as the knowledge of UNIX libraries is
concerned, one of the excellent books on C does provide thorough coverage
of this area:

	Samual P. Harbison and Guy L. Steele,
	C: A Reference Manual, 2nd Edition,
	Prentice-Hall, 1987

     Something that may help with the more difficult parts of C for
beginners is:

	Alan Feuer,
	The C Puzzle Book,
	Prentice-Hall, 1982


    Hmm, COBOL???  I remember an absolutely impossible 800 line COBOL
program I once met up with in the seedy IBM world many moons ago......

>   Also, how long do  you think people need to be trained before they are
>   productive? If anyone has experience in this area that they would like
>   to relate,  (preferably something  like lines  of code/day or  time to
>   complete an (easy, medium, hard) module of  x length, please e-mail me
>   and I'll summarize.

    That depends upon the individual and their previous experiences.  I 
mean, is C the *only* new element for these people to learn?  Will they
be moving from something like MVS to UNIX as well?  Is there at DBMS
involved?  Is this a new application area for these people?  There are
a lot of factors that can come into play here that are often overlooked.

>2. C programming guidelines/standards.  I know Plum publishes a  book  on
>   this, but does anybody else have any words of wisdom? I'd like to skip
>   formatting issues  COMPLETELY (braces,  indentation, etc) and focus on
>   organization,  modularity,   portability,  questionable  practices  to
>   avoid, etc.  (No, I don't expect a  "cookbook" to turn bad programmers
>   into good ones!)  Again, please respond via e-mail if possible.
   

    We used Plum's book back in late 1983 to start with.  However, we went
through it page by page and classified each item as a must,  a nice practice
but not required or not applicable.  I don't know how up to date the book is
now, but it is one of the few books on the topic.  I would recommend reading:

	Andrew Koenig,
	C Traps and Pitfalls,
	Addison-Wesley, 1989


    This book, while relatively compact, contains a wealth of programming
experience with C.  It has contributions from many experience C programers
from real life experience.


     For programming style, in general, the bible is:

	Brian Kernighan and P.J. Plauger,
	The Elements of Programming Style, 2nd Edition,
	McGraw-Hill, 1978

     The examples are in FORTRAN and PL/1, but are very much applicable
to almost any procedural language.


-- 
George W. Leach					Paradyne Corporation
..!uunet!pdn!reggie				Mail stop LG-129
reggie at pdn.nm.paradyne.com			P.O. Box 2826
Phone: (813) 530-2376				Largo, FL  USA  34649-2826