Wish Project Statistics

abhishek007p

Active Member
Licensed User
i would like to suggest a new feature called 'Project Statistics', where the user can get stats on the project. you can add menu to Project menu and information is displayed in small window.

* No of Lines of Code
* No of Libraries Used
* No of Activity Module
* No of Class Module
* No of Code Module
* No of Service Module

Edit: see the screenshot i posted below.

Thanks,
Abhishek
 
Last edited:

klaus

Expert
Licensed User
And what is the purpose of these statistics ?
I'm sure that the final user doesn't care about this.
As a developper you know what you are doing.
 

abhishek007p

Active Member
Licensed User
a developer asked me to tell him the no of line of code and other details like libraries used so he can estimate the cost of source code. and i often ask this question from my developer too.

anyway, just a suggestion.
 
Last edited:

NJDude

Expert
Licensed User
a developer asked me to tell him the no of line of code and other details like libraries used so he can estimate the cost of source code.
That's really silly, the number of lines means nothing, in fact, if that "developer" is asking for a price depending on lines of code I'm going to type 4 pages of "comments" so my price goes up :D.
 

abhishek007p

Active Member
Licensed User
Uploading a screenshot of VB6 project stats generated by a popular add-in named MZTools. It separately shows code and comment. Thats what i meant by stats.

stats_vb6.PNG
 

sorex

Expert
Licensed User
almost 3200 line for an autoshutdown?

a scheduled task to "shutdown /s /t 0" was not good enough? ;)

stats can be nice but I never felt the urge to have this for coding projects unless it's multi coder git/svn based or something.
 

abhishek007p

Active Member
Licensed User
almost 3200 line for an autoshutdown?

a scheduled task to "shutdown /s /t 0" was not good enough? ;)
That is because of lots of code reuse. :p:D and that tool do a lot than just shutdown the pc. a scheduled task is fine for me but not for average user, so a app for them for $10 only.

i code in a multi coder environment so find this feature useful, atleast for me VB projects.
 

JakeBullet70

Well-Known Member
Licensed User
I like the idea. But for me its information that I use.
 

Troberg

Well-Known Member
Licensed User
I've used such tools professionally a lot. Face it, your boss will want an estimate of when it will be done, and different programs have different complexity and that affects how fast you work.

I've done, for old VB6, a code statistics generator. Pretty simple, but it gave a good sense of how complex a project was. It calculated (among other things):
* Number of lines.
* Percentage empty lines.
* Percentage of comment lines (any line that had a comment, either full line or simply the end of the line).
* Average line length (blank lines excluded).
* Median line length (blank lines excluded). Useful for getting a sense of how "meaty" the lines are. Probably should have done a histograph on line length as well as I had collected the data anyway to calculate median), but didn't get around to it.
* Number of declared external DLL functions.
* Number of variables.
* Number of subs.
* Number of forms.
* Number of controls in forms.
* Number of classes.
* Number of selections (if, select...).
* Number of iterations (for, do...).
* Number of selections/iterations adjusted for complexity (first nesting level counted as 1, second for 2 et cetera).
* Number of recordsets.

With this, it was easy to estimate the complexity of a program. For example, a typical database frontend had a reasonable amount of database recordsets, realtively short lines, many forms and Controls, relatively few subs and low complexity (nesting). However, a complex data grinding system had many more recordsets, longer lines, fewer forms and controls, more variables, more arrays, more selections/iterations, much higher complexity (nesting), more classes and so on. Other warning signs for complexity is many declared external DLL functions, many file operations, many UDT's and so on.

It's easy to run the tool on the project, and then see that, for the more complex project, a change will take longer, and we'll need to put a more experienced programmer on it. For the database frontend, it's faster and it's simpler programming, so we can put a newbie on it.

This allowed us to accurately estimate how long a change would take, taking into account the specifics of the project. When you bill the customers for your time, you need to be accurate.
 
Top