Count lines of code?

  • Thread starter Thread starter Bill
  • Start date Start date
B

Bill

Is there a utility available that will count the
lines of code within a project? I.e., the code
sheets of forms, reports and modules?
Thanks,
Bill
 
This function will do it...just call it from the immediate window. If you
really want a utility, you might look at Total Access Analyzer.


Function CountCodeLines() As Long

Dim db As Database
Dim cnt As Container
Dim rpt As Report
Dim frm As Form
Dim mdl As Module
Dim doc As Document

On Error Resume Next

Set db = CurrentDb()
Set cnt = db.Containers("Forms")
For Each doc In cnt.Documents
DoCmd.OpenForm doc.Name, acDesign
For Each frm In Forms
If frm.Name = doc.Name Then
If frm.Properties("HasModule") Then
Set mdl = frm.Module
CountCodeLines = CountCodeLines + mdl.CountOfLines
End If
End If
Next
DoCmd.Close acForm, doc.Name
Next

Set cnt = db.Containers("Reports")
For Each doc In cnt.Documents
DoCmd.OpenReport doc.Name, acDesign
For Each rpt In Reports
If rpt.Name = doc.Name Then
If rpt.Properties("HasModule") Then
Set mdl = rpt.Module
CountCodeLines = CountCodeLines + mdl.CountOfLines
End If
End If
Next
DoCmd.Close acReport, doc.Name
Next

Set cnt = db.Containers("Modules")
For Each doc In cnt.Documents
DoCmd.OpenModule doc.Name

Set mdl = Modules(doc.Name)

If mdl.Name = doc.Name Then
CountCodeLines = CountCodeLines + mdl.CountOfLines
End If
DoCmd.Close acModule, doc.Name
Next

End Function
 
I created an Access Add-In called the "Albert Kallal Database Statistics"
that does exactly this. The add-in will make a one-page report that lists
the total number of lines of code in Modules, Forms, and Reports (a
sub total for each and a grand total) as well as a count of each other
type of database object (a sub total for each category and a grand total).

Once installed (takes less than a minute) all you have to do is
Tools | Add-Ins | Albert Kallal Database Statistics. Poof!
After a short time a slick report is displayed on the screen. Easy as pie!
A few words of warning though. This will have some INTENSE screen
flickering so you may want to look away from the monitor. Serious!
Also, make sure you always have good backups of your file before
launching since it is intense code! Don't miss that step.

I am awaiting word back from Albert about the possibility of having him post
it on his web site where anyone can download it. In the meantime, I do not
believe he would have a problem if I sent you a copy. If you do wish to have
a copy please let me know where you would like it sent to (please mung the
e-mail address so you won't get spammed!). There is one version for Access
97 and one for 2000 which works with Access 2000, 2002, and 2003.
I will need to know which version you need.
 
Jeff Conrad said:
I created an Access Add-In called the "Albert Kallal Database Statistics"
that does exactly this. The add-in will make a one-page report that lists
the total number of lines of code in Modules, Forms, and Reports (a
sub total for each and a grand total) as well as a count of each other
type of database object (a sub total for each category and a grand total).

Jeff,
I just ran the Statistics report of MzTools and it returns this information:

File-File Type-Code Lines-Comment Lines-Total Lines-Procedures-Controls

Project Group Project Group 1,777 (90%) 205 (10%) 1,982 174 0
test (test.mdb) Project 1,777 (90%) 205 (10%) 1,982 174 0
AddressOf Module 35 35 70 2 0
Form_CalMike VBA Document 216 3 219 56 0
Form_CalMike2 VBA Document 32 7 39 7 0
Form_Dummy VBA Document 15 0 15 2 0
Form_frmAddAppointmentDates VBA Document 26 0 26 1 0
Form_frmCalendar VBA Document 57 0 57 5 0
Form_frmCalendar1 VBA Document 82 0 82 16 0
Form_TestCbo VBA Document 39 2 41 4 0
Form_TestForm VBA Document 41 0 41 5 0
Form_TestFormSub VBA Document 6 0 6 1 0
Form_TestListBox VBA Document 63 17 80 6 0
Form_TestWebBrowser VBA Document 13 0 13 2 0
Form_UsaMap VBA Document 10 0 10 3 0
Form_WindowsCalcDemo VBA Document 50 3 53 5 0
main Module 358 24 382 33 0
modCalendarScheme Module 59 1 60 1 0
modDialogColor Module 31 8 39 1 0
modMCAccessWindow Module 36 0 36 1 0
modMCAVIError Module 13 2 15 1 0
modMCAVIFunctions Module 112 12 124 6 0
modMCCurrentDBDir Module 9 5 14 1 0
modMCDayClick Module 38 3 41 1 0
modMCDetermineMonthInformation Module 35 2 37 1 0
modMCGlobalVariables Module 22 0 22 0 0
modMCMiniCalendar Module 89 17 106 1 0
modMCMonthToNumber Module 13 1 14 1 0
modMCNumberToMonth Module 5 0 5 1 0
modMCSysTray Module 209 54 263 7 0
modMCWeekOfDates Module 36 9 45 1 0
Report_repTestDate VBA Document 26 0 26 2 0
subMain Module 0 0 0 0 0
TestNoExplicit Module 1 0 1 0 0

I am wondering in what way your addin differs from MzTools?
 
Jeff,
I just ran the Statistics report of MzTools and it returns this information:

<<Output Snipped>>
I am wondering in what way your addin differs from MzTools?

Hi Mike,

I have used MzTools before, but it has been a while.

Here is the report output from one of my databases:
Lines Of Code In Modules: 9714
Lines Of Code In Forms: 24076
Lines Of Code In Forms: 6327
Total Lines Of Code: 40117
Number Of Tables (Including System): 40
Number Of Tables (User Defined): 33
Number Of Queries: 113
Number Of Forms: 103
Number Of Reports: 84
Number Of Macros: 3
Number Of Modules: 45
Total Number Of Database Objects: 388
 
Jeff:

You keep track of all that in a single database? Hats off...you must have a
mind like a steel trap. :o)

My biggest app has roughly the same number of lines, but I split it into
reference libraries (9) and a DLL, plus the main database and back end.
39,510 lines of code, 49 user defined tables, 1,133 queries, 49 reports, 151
forms and growing! I think splitting up large apps like this into
libraries of functionality makes it more managable.
 
Hi Paul,
You keep track of all that in a single database?

Yes, but it is split into a FE/BE. The report counts the table links.
Hats off...you must have a mind like a steel trap. :o)

Steel plate maybe.
My biggest app has roughly the same number of lines, but I split it into
reference libraries (9) and a DLL, plus the main database and back end.
39,510 lines of code, 49 user defined tables, 1,133 queries, 49 reports, 151
forms and growing! I think splitting up large apps like this into
libraries of functionality makes it more manageable.

Good golly that is a lot of queries Paul! Who has the steel trap mind?
:-)

This is a growing program to say the least. I am receiving feedback as
to what the users would like to see added, as well as including new
features that I have come up with. This next version will see a ton of new
stuff added. However, at the same time it is growing, I'm actually
condensing things somewhat. For example, I used to have three different
forms (and queries) for entering Vendor information. Now I condensed
that all into one form and query.

Keeping track of things sometimes can be a little hairy yes. What I am
doing right now is stripping out each menu of common tasks into its
own separate MDB file. This way I can work on all the queries, forms,
reports, etc. for that particular area. For example, all the Vendor stuff
is now in one file. When I am all completed I will bring everything back
together again in one file.
 
Yes...it is a mind numbing number of queries. That doesn't even count SQL
in VBA. :o/

I bit the bullet version before last splitting it into libraries, but I'm
glad I did. It really is much easier to work on now...I just released v6.0
and dev time was much less even with some major changes....think I added
over 200 queries this last version. I wrote a little app that builds all
the MDEs in a batch, so, that part is easy too.

You really should look into using libraries, it would save you from
stripping stuff out and putting it back in. That has to be a job all by
itself! I broke mine up by functionality, i.e., one for reports and
queries, one for donation functionality, one for pledge functionality, etc..
Plus, I've got it where specially designed Access add-ins can be loaded in
my app....no reference for those.

Now, I guess we both have to pray that Microsoft doesn't pull the rug out
from under us by making some radical change in direction for Access.
 
Yeah...I'm really not interested in see Access move to VB.NET. Jeez...users
have enough problems learning fairly simple VBA. And I have yet to see a
compelling reason for using it as a developer....other than that is where
Microsoft wants everyone to go. IMO, VB.NET was a pretty stupid move on
Microsoft's part.

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com


MikeB said:
Now, I guess we both have to pray that Microsoft doesn't pull the rug out
from under us by making some radical change in direction for Access.

VBA dot NOT ??
 
Hi Paul,

I may have to break the application apart into various sub-sets at some
point, but for now everything is humming along just fine. I also do not
have any experience with creating DLL files at this point.

Personally, I'm hoping Microsoft will just continue to add new features
to Access and release many, many new versions in the future. I may
have to be put in isolation if they choose not to. <g>
 
Jeff,

Apparently (e-mail address removed) is a mung'd address, as my
e-mail was rejected. I should have realized that from the start.

In my e-mail, I'd asked you to send me Albert's statistics add-in.

If you would please, send it to me at (e-mail address removed) (the domain
being jps.net)

Thanks,
Bill Stanton
Graeagle, CA
 
Hi Bill,

You are correct; my posted e-mail address goes to Never-Never Land.
Keeps the SPAM down.

Sure, I can send along a copy of the Add-In.
Do you need the 97 version or the 2000 version?
The 2000 version works with Access 2000, 2002, and 2003.

And just to double check, the file should go here:
stanton
at
jps
dot
net
Correct?
 
Jeff,
Yes, the e-mail address is correct as you note.

My current environment is Office 2000, so the 2000
version will work just fine.

Earthlink owns JPS and I have the spam blocker turned
on so I don't get bombarded with spam. Thus, since I
don't have your address, I'll keep an eye out for your
e-mail in the spam folder at Earthlink, so I can "open
the door" to your address when it arrives.

Thanks,
Bill
 
Hi Bill,

File has been sent to the address you provided.
Subject line will be:
"Access Add-In You Requested From The Newsgroup"
Please follow these steps to install the Add-In.
Also, please read the important information in Step 4!

The Add-In will not work on MDE files for obvious reasons.

1. Unzip the file AKStats.MDA to your Office or Access directory
to easily find it when we install the Add-In.

2. Now open any Access database and go up to "Tools" on the main
Access menu bar. From there go down to the option called "Add-Ins".
This sub-menu will list any installed Access add-ins on your system, as
well as an option called "Add-In Manager". Click on the option called
"Add-In Manager" and a new screen will appear.

3. The box will display a list of available add-ins on the left side. Depending
upon where you unzipped the add-in file, you may see the Albert Kallal
Database Statistics already listed in this box. If the file is listed, click on the
option to highlight it and then press the "Install" button to complete the installation.
There should now be a little "x" next to the option meaning it has now been
installed. If you do not see the add-in listed in this box simply click the button
called "Add New..." where you can browse for the location of the file. Once
you find the file and click on it in the browse window, you will be taken back
to the Add-In Manager screen. Now you should see our add-in listed in the
box with a "x" by it meaning it has been successfully installed. If not, highlight
the option and then press the "Install" button to complete the installation. Hit the
"Close" button on the Add-In Manager when finished.
That's it, now we're ready to use the utility!

4. Before launching the Add-In on a database, make sure you make at least TWO
backups of your database file. Why two? Two is better than one backup. The
add-in will be accessing every bit of your code so if there is ANY possible VBA
corruption in your database, Access will cough up a hairball. I specifically tested
it on a database with corruption for this purpose and it crashed every time. So,
PLEASE make backups before beginning. One last thing, look AWAY from the
monitor because it will have some serious screen flashing!!

5. To launch the add-in, simply open any database you wish to document and go
up to Tools | Add-Ins and click on the new option "Albert Kallal Database Statistics".
Depending upon the number of objects in your database the utility should only take a
short time to create the report and display it on the screen. It will be a one-page report
that you can just print. Doesn't get any easier than that!

Please post back to the newsgroup when you receive the file and if you have any
problems. The e-mail was being sent from a "dump" e-mail account and will not be
checked if a reply is sent. The ONLY way I will know if you received the file is
through the newsgroup.

Also, besides myself, Albert, and one other person, no one else has used this utility
so I woulnd't mind knowing if everything works OK. Feedback is welcome.

Hope you find it useful.
 
Jeff,
As I would expect, Albert's code works great. I tried it out
on one of my small databases, using the source mdb file from
which I maintain the code and from which I create the mde
file for the end users.
Thanks very much,
Bill

Snapshot of test follows:
========================================================
Database Statistics

C:\GCC\GCC-Source V4.8.4.mdb

Lines Of Code In Modules: 1130

Lines Of Code In Forms: 3084

Lines Of Code In Reports: 391

Total Lines Of Code: 4605

Number Of Tables (Including 25

Number Of Tables (User Defined): 20

Number Of Queries: 29

Number Of Forms: 29

Number Of Reports: 12

Number Of Macros: 0

Number Of Modules: 20

Total Number Of Database Objects: 115
========================================================
 
Hi Bill,

Excellent, glad to hear you received the file OK and
everything worked perfectly. Also, thank you for the
feedback and even displaying the output. Cool!
 
Back
Top