lines of code!!

I think i have worked out why corporate software products like adobe and MS are bloated to hell

We had an american guy apply for a job with us and my boss was laughing at his CV because it had how many LINES of code he has produced for this that and the other. When asked he said that in the US sometimes big giants use lines of code (inc comments) from source control to check how productive an employee is being!! He also says it encourages complete non-structuring where it can be possibly got away with.

LOL!

From now on i am doing this!:

//inert 4 line essay on 
//what the next 100 lines do
//they are going to 
//print some options

int a;
string as= a.tostring();
int y;
int x;

x=100;

//absolutely unnessecary comment
a++;
y=100;
as= a.tostring();
strtodisplay=" Option:"+ as   +" "+ stringoption[a]
screen.writeline(strtodisplay,x,y);

//absolutely unnessecary comment
a++; 
y+=10;
as= a.tostring();
strtodisplay=" Option:"+ as   +" "+ stringoption[a]
screen.writeline(strtodisplay,x,y);

//absolutely unnessecary comment
a++;
y+=10;
as= a.tostring();
strtodisplay=" Option:"+ as   +" "+ stringoption[a]
screen.writeline(strtodisplay,x,y);

Perhaps i will get a payrise! :D

You can use the \ formatter to make a new line after each token.

I think a better measurement of the productivity of programmers is to ask them how fast they can code it without errors. If they say it takes them 80 hours, tell them to type faster and remind them that you don't pay for bugs and errors!

Or maybe ask them how many lines of code they need to perform a concrete task (more lines is worse). That would have meaning...

Or it may be completely irrelevant :-p

How many lines to sort a list of integers...

Hmm... about 6. Bubble Sort :-)

But wait... surely a Quick Sort would be faster ?

Oh.. okay.. lots more than 6...

Last year on Perlmonks.org there was a nice topic about this. How it's completely unnecessary to comment lines of code that actually explain themselves.

Since a month or 2 we're (I'm) finally using Subversion and if my boss was to check that... If you diff the changes then sure, it might not look that much. But people shouldn't forget usually a thought process on how to solve the problem was also required, including testing the code. If he was saying there are not enough changes in the code which would imply that I'm not working hard (enough) then I'd say 'up yours with it'.

I've been over code made by a others more than once and have seen a lot of unnecessary comments. I only comment stuff that needs explanations. Usually this is at the start of a routine (what is it supposed to do?) and some explanations WHY I'm checking for a certain value. All to often I've seen comments like 'Checking action variable if it equals string "blaat"'. Right, as if I couldn't see that. I want to know WHY.

I think comments in code should not explain the WHAT's, but the WHY's. In some cases with obfuscated code a WHAT explanation is fine, but only if it's really unreadable.

The why is most times not an absolute term, but you need to recurse the why from the answer you got when asking why, until you get to an abstract enough answer. That's what kids do anyway, and they are right!

Counting lines of code is just silly. I've sometimes spent a day writing a negative number of lines of code, by cleaning up messy code and structuring it, which has made the end software better.

The only thing that should really count is the quality improvement to the end product, though to track this you would actually need a non-lazy management that followed up things.

Actually, the animation industry sometimes does the same, and pays people by the number of frames they animate. This can be almost equally silly, when one animator might get a relatively static scene with some minor animation, and another might get one with 20 people in a fight or running. :)

Or in fact, a management that could actually read it ;-)

I think it's silly too, but the last time I went for an interview they said it was required to put down the number of lines of code.

When I've conducted interviews I ignore number of lines written and number of program written. I ask about what was the hardest program they ever had to write, why was it hard, and how did they solve it. Then I would ask what their customers think of their programs.