Hi,

How many lines of code should an average professional game programmer be able to create with all other tasks such as maintaining or porting of existing code included in each day?

I have about 4 hours each day and six days per week for coding, so what is about the average amount of work that would be expected in this timeframe for a pro? ( I am at a snails pace, so don't ask about me! )

It would be good to know for the sake of a goal to reach. Does anyone have a website link which gives these numbers?

there is no magic number, it really depends with how well versed you are in a particular subject that your writing code on, for example if i'm researching a new idea/concept, i might write at an upper most a hundred lines in a day(most likely far less), however if i'm starting a new project, and am just building the baseline code, i might crank out a few hundred lines in a single day, more so if i have a clear design of how to accomplish something. of course then their's debugging that code to make sure their arn't problems(which can sometimes take hours depending on the complexity of your project).

but again, and i can't stress this enough, their isn't a specific number, there's just what you are able to do with what your given, everyone has their own pace.

This is a bad metric to use as a goal. The focus should be on code quality: maintainability, legibility, efficiency and complexity of algorithms, and reduced bug counts. The random elements of programming like debugging, thinking about code design, and forming solutions, mean that the target is way too mobile day-to-day.

I would argue that you hit milestones and release products faster if you have higher quality, slower-written code than if you have incredibly verbose programmers who can hammer out LOC like crazy.

Lines of code is a very poor measurement tool for several reasons:

A) One line of code in one language at a higher level of abstraction might be worth twenty in another language.
B) A poor programmer might write 10 lines of code when 5 might suffice (not properly re-factoring into functions), or a poor programmer might write 5 lines of code when 10 would be better (example: skipping error checking).
C) A poor programmer might write 50 lines of code, and have to re-write it later because the first time it was done wrong. Does that mean he wrote 100 lines of code, despite only 50 ending up in the final project?

This is a bad metric to use as a goal. The focus should be on code quality: maintainability, legibility, efficiency and complexity of algorithms, and reduced bug counts. The random elements of programming like debugging, thinking about code design, and forming solutions, mean that the target is way too mobile day-to-day.

I would argue that you hit milestones and release products faster if you have higher quality, slower-written code than if you have incredibly verbose programmers who can hammer out LOC like crazy.

[quote name='3Ddreamer' timestamp='1357851227' post='5020009']
I know that it is risky for a person here to stick the neck out and write an estimate of the average because of counter considerations.
[/quote]

That has nothing to do with it. It's not a useful metric, and doesn't actually represent skill or, well, anything if an average were calculated. You'll know you're writing good code when you're writing good code: solving more complex problems, spending less time redesigning, and reusing code with less hack-work to get it to play nice in a new role.

Entire commits can be done, representing very useful work, solving dozens of game-halting crash bugs, and the LOC of a project might change by +/- 10. People are trying to tell you that this isn't a way you should be measuring your progress, because it's a meaningless statistic.

According to version control, I have on average written a negative number of lines per day.

This is mostly due to the fact that I joined an in-progress project, and spent quite a lot of time refactoring/rewriting areas of the project that were not up to scratch.

But my point is that a good developer tends to write vastly less code than a poor developer, while getting more done. Thus, lines of code is an awful metric of developer productivity or quality.