Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!fluke!ssc-vax!dmg
From: dmg@ssc-vax.UUCP (David Geary)
Newsgroups: comp.lang.c
Subject: Re: C Programming Estimates
Message-ID: <2537@ssc-vax.UUCP>
Date: 9 Mar 89 17:19:59 GMT
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 55


Larry Podomolik writes:

>Come on,  guys.  I  can't believe  nobody has any  advice/opinions  on
>estimates  and/or standards for C programming.  However, I  only got 1
>reply  to  my last  posting.  Our news  feed was erratic for a  while;
>maybe some were just lost.

  Ok, ok, here's a reply ;-)

>Anyway, I'm asking again for information on the following subjects:

>1.  C programming estimates for programmers of various levels  working
>on programs  of  varying  complexity.  I would  prefer  something like
>lines of code/day or time to  complete an (easy, medium,  hard) module

  No wonder Larry's only gotten one reply!  This question involves
so many different variables that it is almost un-answerable.  To me
lines code/day is a pretty useless statistic and a gross way to measure
productivity.
  What's easy ? medium ? hard?

>of x  length.  Also, how  long do  you think people need to be trained
>before they are productive?

  What do you mean by productive?  What do you mean by trained?  I often
have people ask me how long it takes to learn C.  It depends on what
you want to use it for.  Want to just write "hello world" on the screen?
You can learn "C" in about 1/2 hour.  Want to write an arcade game
or write a compiler?  That may take a little longer ;-).

  A better question would be:

 "We are writing a database package for a Sun workstation  and need someone
to debug some C code that has some assembly mixed in.  How long do
you think someone who has a computer science degree, but has only used
C for "trivial" code needs to be trained?"

  IOW - your question is just too vague.

>2.  C programming  guidelines/standards, EXCLUDING  formatting issues,
>but   definitely  including  organization,   modularity,  portability,
>questionable practices to avoid, etc.

  I don't know of any guidelines/standards that are tangible.  Some shops
set up their own standards to promote readability of code between programmers.
There are many, many issues when it comes to organization, modularity, and
portability, etc.
  

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ David Geary, Boeing Aerospace,               ~ 
~ #define    Seattle     RAIN                  ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~