It doesn't matter whether its one function with 500 lines, or 50 methods with 10 lines each, it's the same count of
50 methods is going to be easier to maintain and less buggy was all I was saying.
Not so much as a metric itself.
You'll possibly argue that you simplify logic in the process, saving some LOC - but from my experience, unless some code reuse could be put in place no meaningful reduction in LOC would occur.
With 500 lines I am sure I could find code reuse but its not just about code reuse its about readability/clarity and context.
Also, suppose I put the entire Zend Framework library under my project, though I don't know yet exactly what components I will be using. I will raise the LOC considerably without having written one line of implementation - how is this a good metric for the quality of my project?
I didn't quite mean it in that way...SLOC as a total number of lines is useless, yes...bigger applications will likelly have more lines of code...but when you add context, such as lines per module, per method, per class, those numbers become much more useful.
won't deny that commenting is personal preference, though most serious projects have significant portions of it
Like I said I have very few comments and no bugs or security holes that I am aware of...just unfinshed pieces.
Most serious projects? The last 5 projects I have worked on had such poor commentation I had to figure out the code by stepping through it manually anyways, so what was the point of having the comments other than to distract me from reading the code?
Can you give me an example of a complete function where you needed comments? Also make sure the comments are specific to the context of the function only. That is your not commenting on the fact that if a variable is removed it will have a reaction, etc...
I'd like to see an complete example before I would agree. Just find a function with no or minimum dependencies and use that.
As for docblocks, I add them mostly for public methods (ie, my API) so they shouldn't change often. They are also conveniently generated by my IDE from the method definition.
Even the public API changes frequently in my case...obviously between versions I would not change an API once others were using it but until it's set in stone I treat it like a private or protected and refactor when needed.
When I see well commented code (not over commented, not under commented) I appreciate the effort the developer went through to allow others to ease in to their project. Remember that comments are mainly for other developers (since most developers believe their own code is very readable, which it is but mainly to them).
I realize that. Comments are best written by someone else for that very reason. Have a period of time when someone who has no knowledge of the implementation go in and comment the code. Recording the steps and caveats as they go will prove far more helpful than the original developer hammering out what he thinks makes sense at the time of implementation.
Then ask yourself...if you have to comment...is there any way you can simplfy your codebase so that the code was self describing and didn't need comments.
Note: While I don't comment I do document quite thouroughly. Before entering the codebase one might read the docs and become effective as a developers within hours, not days, weeks or months.