larry@zeek.UUCP (Larry Podmolik) (03/04/89)
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. 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 of x length. Also, how long do you think people need to be trained before they are productive? 2. C programming guidelines/standards, EXCLUDING formatting issues, but definitely including organization, modularity, portability, questionable practices to avoid, etc. Thanks in advance, Larry
jeenglis@nunki.usc.edu (Joe English) (03/06/89)
larry@zeek.UUCP (Larry Podmolik) writes: >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 ^^^^^^^^^^^^^^^^^ >of x length. Also, how long do you think people need to be trained >before they are productive? I suggest that you read _The Mythical Man-Month_ by Fred Brooks. If you're asking about lines of code, I would guess that you're looking for the wrong sort of information entirely. >2. C programming guidelines/standards, EXCLUDING formatting issues, >but definitely including organization, modularity, portability, >questionable practices to avoid, etc. Check out _C Traps and Pitfalls_ (by Andrew Koenig?? I forget). There are no universally applicable programming standards, the important thing is just to *have* some in your shop. For organization and modularity, I found the Yourdon Press series on structured design to be somewhat helpful, although the Yourdon methodology doesn't fit well in some cases with object-oriented design (which you should also look into. Sorry, I don't know of any good references on O-O.) >Thanks in advance, Larry --Joe English jeenglis@nunki.usc.edu
dmg@ssc-vax.UUCP (David Geary) (03/10/89)
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 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~