sc2y@vax5.CIT.CORNELL.EDU (06/12/89)
In article <15526@pollux.UUCP> leff@smu.edu (Laurence Leff) writes: >A project needs a person with a proven capability of generating >a thousand lines of debugged C a week. Okay, how about this? /* compute square root of a number if less than 1000 */ float comp_sqrt(x) int x; { if (x == 1) return (sqrt(x)); else if (x == 2) return (sqrt (x)); else if (x == 3) return (sqrt (x)); /* ... et cetera ... */ else if (x == 999 ) return (sqrt (x)) ; else return (ERROR) ; } Do I get the job?
Tim_CDC_Roberts@cup.portal.com (06/13/89)
In <18783@vax5.CIT.CORNELL.EDU>, sc2y@vax5.cit.cornell.edu asks with tongue in cheek: >>A project needs a person with a proven capability of generating >>a thousand lines of debugged C a week. > >Okay, how about this? > > /* compute square root of a number if less than 1000 */ > float comp_sqrt(x) > int x; > { > if (x == 1) > return (sqrt(x)); > .... > > Do I get the job? Since you didn't declare "double sqrt (double)", and you are passing an int to a function expecting a double, and returning a double for a function that is supposed to return a float, this function will fail on any machine where sizeof(int) != sizeof(double) or sizeof(float) != sizeof(double). Since the specifications clearly called for "a thousand lines of DEBUGGED C a week", you obviously do NOT get the job. Sorry. I hear McDonalds is hiring. Tim_CDC_Roberts@cup.portal.com | Control Data... ...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you.
flint@gistdev.UUCP (06/14/89)
The code below obviously was by an inexperienced programmer:
if (x == 1)
return (sqrt(x));
It should have been written thusly: (An immediate 400% increase in
productivity, and you can point to all the wonderful comments!)
if (x == 1)
{
/* return the square root of 1 */
/* (to the calling routine) */
return (
sqrt(x)
);
}
More seriously, I was asked to come forward with some lines-of-code produced
numbers for the people on my staff. I knew the results weren't going to mean
squat in advance, but I did it anyway. The results (over a year) ranged from
70,000 lines of code to 2,000 lines of code, for a group of about 15
programmers. The individuals I want working for me are the ones that spend
2 days thinking about the problem and come up with a creative idea so that
they can solve it with 10-100 lines of code, not the ones that spend those 2
days cranking out 2000 lines of brute-force code. (My staff varies widely
in their duties: some people are doing maintenance, where they spend 2 days
trying to figure out what is causing a bug, and then add 1 line to fix it,
others are using programs to modify/create code (like running a utility that
automatically creates prototypes in old code), others are spending all their
time writing designs and none writing code, etc.) I have seen programmers
with a "we need something like this routine in 10 places, but it has to
be slightly different in each, so we'll copy it into all 10 places and modify
one line" mentality that really crank code out. Give me the guy who knows
enough to add a parameter to the routine anyday.
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165
INTERNET: flint%gistdev@uxc.cso.uiuc.edu
UUCP: {uunet,pur-ee,convex}!uiucuxc!gistdev!flintfozzard@boulder.Colorado.EDU (Richard Fozzard) (06/15/89)
>In article <15526@pollux.UUCP> leff@smu.edu (Laurence Leff) writes: >>A project needs a person with a proven capability of generating >>a thousand lines of debugged C a week. > Enclosed is my resume: { ; ; ; /* 994 lines removed for clarity */ ; } Do I get the job? ======================================================================== Richard Fozzard "Serendipity empowers" University of Colorado fozzard@boulder.colorado.edu (303)492-8136 or 444-3168
greg@sce.carleton.ca (Greg Franks) (06/16/89)
In article <7800012@gistdev> flint@gistdev.UUCP writes: >...I have seen programmers >with a "we need something like this routine in 10 places, but it has to >be slightly different in each, so we'll copy it into all 10 places and modify >one line" mentality that really crank code out. At a former employer, we called the same sort of operation "case and paste". Eg. "Well, this new feature is almost the same as all of the others but does this thing a little differently. No problem..." <select> move <cut> move <paste>... and add a new case selector. No wonder our embedded applications kept running out of memory. *sigh* >... Give me the guy who knows >enough to add a parameter to the routine anyday. > I'll second that. -- Greg Franks Systems and Computer Engineering, utzoo!dciem!nrcaer!sce!greg Carleton University, Ottawa, Ontario, Canada. uunet!mitel!sce!greg greg@sce.carleton.ca from Ottawa Ont, where life in the fast lane is skating two inners!
john@frog.UUCP (John Woods) (06/24/89)
In article <7800012@gistdev>, flint@gistdev.UUCP writes: > More seriously, I was asked to come forward with some lines-of-code produced > numbers for the people on my staff....The results (over a year) ranged from > 70,000 lines of code to 2,000 lines of code. (My staff varies widely > in their duties: some people are doing maintenance, where they spend 2 days > trying to figure out what is causing a bug, and then add 1 line to fix it, Uh oh. I'm in trouble now. I spent one hour yesterday debugging something that I fixed by removing one line of code. Let's see, over a year, that works out to a productivity figure of, uh, -2000 lines of code. I better take up beekeeping instead... -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu People...How you gonna FIGURE 'em? Don't bother, S.L.--Just stand back and enjoy the EVOLUTIONARY PROCESS...
mouse@mcgill-vision.UUCP (der Mouse) (06/27/89)
In article <19436@cup.portal.com>, Tim_CDC_Roberts@cup.portal.com writes: > In <18783@vax5.CIT.CORNELL.EDU>, sc2y@vax5.cit.cornell.edu asks with > tongue in cheek: >>> A project needs a person with a proven capability of generating a >>> thousand lines of debugged C a week. >> Okay, how about this? >> /* compute square root of a number if less than 1000 */ >> float comp_sqrt(x) int x; { >> if (x == 1) >> return (sqrt(x)); >> .... > Since you didn't declare "double sqrt (double)", If we're being picky, he also didn't say the code he exhibited was the entire file: it could have been just one routine extracted from a file which quite possibly had a line "#include <math.h>" above the sample. > and you are passing an int to a function expecting a double, and > returning a double for a function that is supposed to return a float, > this function will fail on any machine where sizeof(int) != > sizeof(double) or sizeof(float) != sizeof(double). Actually (under the assumptions you made, ie, no declarations), it requires more than just that int and double have the same size - it also requires that for all values 1 to 999, the bit patterns are identical and are passed to sqrt() in the same way. (I expect this excludes all existing C compilers. I certainly *hope* it does!) The "returning a double when supposed to return a float" is specious: return values have always been cast to the proper type for the function, even in Classic C. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu