I just knocked up a little program to count how many lines of code there are in a project. Dunno if anyone else would like to play with it or would find it useful but you can get it here if you want it.
http://members.xoom.com/blvallis/CodeCounter/CodeCounter.zip
If you do use it mail me or leave a message here so I can feel all warm and fuzzy inside

I haven''t tried it yet, but I''d like to because some friends at school always asks me how many lines of code I have written, I personally think that''s pure crap because there''s no way the amount of code can express how good/bad your code is (well, maybe in extreme cases).

Can you make it count Visual Basic source files too, if it''s not too much to ask?

Also, the number of lines doesn''t even accurately depict how much code there is, since some people write condensed code where many lines are long, whereas others write code spread among many lines, with a lot of white space and comments, and function parameters each on their own line.

Just added character counting support, and a few other niceties. Also added preliminary VB support. Havn''t been bothered to parse the FRM files yet so at the moment it includes all of your window details in the count. Ill fix this soon...can anyone suggest a quick way of detecting the start of the code?

I thought about counting the "Begin"''s and "End"''s and when you have matching Begins and Ends you are in the code section. Thats my best one so far...

Also - for VB I currently look at the extensions .BAS .CLS .FRM - are there any others??

In answer to the question about detecting the start of code in VB form files look for lines beginning with ''Attribute''. These follow the form definition and preceed the code (VB5+ only). I dont think you should disregard the form definition though - it provides an indication of the complexity of the form. Perhaps you want to start maintaining different counters for different aspects of the code (how much time where you going to put into this app?)

The cleanest way to analyse VB projects is via the project file (.vbp in VB5,6 and .mak in VB3). This includes the OCX references and project properties as well as a list of all the files which make up the project. Working from this means that you pick up all files regardless of where they are *and* you don''t count files which happen to be in the project directory but aren''t part of the project any longer.

Because I work with large VB projects that share code and use split folders I wrote a utility to copy projects, check for bad file references, compare source intelligently, etc. The code''s pretty crude, but I could cut out the section which parses the project file if that would be useful. Of course it might be faster for you just to pick up a complicated project file and work out it''s structure yourself - there''s really not much to it. Reply here if you want me to email you any of this (I can also provide some sample project files - both VB 3 and 5).

Among all the other things the VB team did right storing the whole project in text files was an often overlooked blessing.

It''s a nifty, fun way to demonstrate the project''scompletion.But a lot of people say code lines are no indicationof the greatness of the project.So why not count procedures?And/Or Classes, structs etc...Just a little idea for you...

It''s a nifty, fun way to demonstrate the project''scompletion.But a lot of people say code lines are no indicationof the greatness of the project.So why not count procedures?And/Or Classes, structs etc...Just a little idea for you...