Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
info@openhub.net
If a project provides high level documentations (by that I mean what explains the big picture, in the vocabulary of the application field as opposed to the documentation of the nitty-gritty of the source code itself) in files beside the source files, then the way you report the ratio of comment / code is not very fair anymore. First you don't count those documentation files as documentation. Then even if they are written in a format you parse, e.g. LaTeX, you report only the number of lines, which is of course highly misleading: source code has much shorter lines than e.g. any LaTeX file.
Inline code documentation is something else than external documentation. As developer you should know that....
The current stats are evaluated by the inline docu only (as I assume, not sure about that point).
So what? Should Ohloh produce more stats about end-user-docu, developer-docu, tester-docu, community-docu ... ?
What is your opinion beside that it's not fair?
Feel free to contribute to Ohcount if you don't like what it does. Parsers are easier to write now.
Does it make big difference, whenever we count it this way or other? Theese stats aren't designed to tell you whenever project A is better
then project B. It's only way to tell some general facts about program (what languages are used? are there good comments etc.)