don't count comment lines as lines of source code

[opensas]

If I'm not mistaken comment lines are being counted

more over, empty lines shouldn't be taken into account either

[calmdev]

I am also wondering about how this works, because my javadoc style comments usually double my SLOC.

[jsoverson]

Yes, they are being counted, we'll get on that. Thanks for the reminder.

[kangax]

This would be a very welcome fix! Some of my files are now reported as having 1000+ lines of code (http://fabricjs.com/report/) because of hundreds of jsdoc comments. As in this file, for example — https://github.com/kangax/fabric.js/blob/master/src/shapes/text.class.js#L57-L199 150 lines of pure comments and that's not even all of it.

[jsoverson]

Should this be closed? Lines are lines and comment lines do add noise which is not something to completely disregard. If source is reported as bloated because of comments that may be something to still consider as a potential maintainability issue.

[localnerve]

Not in my opinion. IMHO, the only comments that add noise are commented out code, not comments that denote purpose or intent. If you can't distinguish between those, then you have to not count comments against maintainability. For density consideration, an example: A five line JS file (a function, 3 lines), and two lines of comments describing what it does to future maintainers (maybe some with not so much experience). That file is (2/5) 40% comments, and IMO reasonable. Too noisy? What is comment bloat?

[opensas]

I would add a different metric, code lines with and without comments, and let each one decide what bloated is...

On Tue, Oct 15, 2013 at 10:33 PM, Alex Grant notifications@github.comwrote:

Not in my opinion. IMHO, the only comments that add noise are commented out code, not comments that denote purpose or intent. If you can't distinguish between those, then you have to not count comments against maintainability. For density consideration, an example: A five line JS file (a function, 3 lines), and two lines of comments describing what it does to future maintainers (maybe some with not so much experience). That file is (2/5) 40% comments, and IMO reasonable. Too noisy? What is comment bloat?

— Reply to this email directly or view it on GitHubhttps://github.com/es-analysis/plato/issues/25#issuecomment-26386701 .

[jsoverson]

I can add an alternate view that counts the logical lines of code. It wouldn't be a count that simply omits comments, but it would provide insight into how much "code" really exists.

[kangax]

@jsoverson That would work for me. As I mentioned earlier, for any JSDoc-documented code, this is kind of a big deal. In cases like this, comments are certainly not bloat (although I know what you meant; cases of overly commented code that's more of a smell than help).

[bjoernklose]

Actually, you could add the comment lines as a seperate metric, which would even make it possible to calculate the code/comment ratios for a given file. Not implying any best practices here, but choice is always good.

Keep up the good work and thanks for what you've done so far.

[DimitrK]

Has any progress been done here?

[darrennolan]

Would welcome this as well. Just removed 60% of bloat from a particular file (unused 'common' functions), but I gave the remaining functions their own docblocks (because yay docs). End result, file 'appears' to be the same length of code.

[jmullo]

+1 for separating:

Lines Of Code Lines of Comments

[Riizade]

I would also appreciate a few separate counts. (SLOC with comments, SLOC without comments, SLOC without comments or empty lines).

I tend to write a ton of documentation, and I'm wary of hitting my coworkers with a 1000 line PR that's really 500 lines of comments, and 500 lines of logic.

[Robert-Ernst]

Bump

[vedmant]

+1