Analysis suggestions

If a project's repository is converted from CVS to SVN it is flagged as having a short history, when actually it has a long history that has been imported in a short time.

Secondly, I'd like to see a project flagged with a warning for having few or no tests.

Finally, I'd like to see a project flagged with a warning for having a lot of comments in the source code, usually a sign of poor code quality.

Sure that's not a flaw in your CVS->SVN conversion process? For example, take CrystalSpace: http://www.ohloh.net/projects/3761/analyses/latest - it was not long ago (1 or 2 years maybe, not sure) converted from CVS to SVN, yet this isn't reflected in the stats at all - they're go back right to when the (back then) CVS repo started.

I've realised why this is. After converting from CVS to SVN we reorganised the source tree. The project is in a subdirectory of the SVN repository, and that subdirectory has only existed since the reorganisation. Is analyser is not taking directory moves into account?

This issue also makes Ohloh ignore any contributors who committed code before the directory move.

This affects about every KDE project - KDE is listed as having 2 years of history ;(

"flagged with a warning for having a lot of comments" ?? and this is supposed to be a poor code quality.... Please excuse me but I don't agree with this statement. Have a look in emacs code. I consider it as one of the best quality source code I have ever seen and it does contain lots of comments inside.

"project flagged with a warning for having few or no tests." I would agree with this in principle. But I don't think there is a way for fair verification of this. There are so many ways to test your software so many projects could be assessed incorrectly just because they use different way to test the code. The good example might be my project - Tigase where one subproject is server code and another subproject is testing framework. From simple analysis it could be considered as a lots of source code without any tests....

The better the code is, the fewer comments it needs. In my work I've found again and again that the more comments there are the worse the code is. There are even code quality tools that use this as a metric for identifying problem areas in a codebase.

I do agree that it's not a two-way relationship: I've encountered many terrible codebases that have no comments. That suggests to me that the current Ohloh metric -- that more comments is good -- is the wrong way round. Many comments is a bad sign, but few comments doesn't provide any information.

As for test coverage, there are many test coverage tools that can determine how well tested the code is. Test code that itself is not covered by the test run has a negative effect on the maintainability of the code, so should count against the project.

Of course, test coverage itself only indicates where there are problems -- where code is not tested. It cannot indicate whether the tests are actually testing anything about the code they are exercising. There are mutation testing tools (e.g. the Jester family of tools) that determine whether the tests are actually doing anything useful, but they are computationally expensive.

funny - i was just about to write that exact same thing. I saw today a prime example of that - a 500 line select statement in a bit of java where every alternate line was a comment... does that mean the code is good?

No, it doesn't. Does it mean that other code, which has a lot of comments, is bad? No, it doesn't.

There's a lot of good code with comments, and a lot of bad code with comments.

I think this is actually good point Christoph. You can not assess quality of code based on amount of comments inside.

In my opinion comments always improve the overall quality of the project. Other developers can only benefit from comments regardless the code itself is a good quality or bad quality.

And what about in-code API doc which are entered as specially formatted a comments like JavaDoc for example? Does it also counts as bad coding practice?

As a developer of a combined application/library, I will completely disagree with the idea of fewer comments being better. I can't expect users of the library to read all the code for the implementation of the API; it is important that there is a relatively high comment to code ratio because the comments describe how to use individual functions/methods, not merely how the functions/methods are implemented.

After careful thought, I'm agreeing with the more comments better camp.

There are some prime examples of code where more comments is a sign of cluelessness "/* Not really sure what this does, but everyone else has it */"-esk stuff.

On the other hand, there is a patch of ground between good code and inspired code where the code is nicely succinct, effective but takes 10 minutes of hard thought to remember exactly how it works. Code that works well and looks nice, but lacks the self-documenting quality that pushes it in toward the inspired area. Sprinkling some well worded comments in the proper places makes such code much nicer to think about ... though overdoing it is worse than not bothering :/

Well commented code (as opposed to code with lots of comments, distinction important) at least demonstrates that the writer understands what their code does, and is happy to help others understand it as well.

Yes, the code is the better documentation to understand what it does. But on the other hand nobody never said that comments were not helping to understand faster and easier. By experience i can tell that a well commented source will be easier to maintain. A bad or non commented code will likely become crappy. Christoph Rupp is true, there's a lot of good code with comments but there is also a lot of bad code with comments (and often it's bad code with short and completely useless comments).