Hello, can someone tell me if I have a count of lines of code for a project in an automatic way, I need to see 3 projects of mine and I do not know how to do it.
Thank you so much !
search the forum, a while back there was talk about this… and I posted a link to a Xojo analyzer… but you’ll have to find the topic yourself… I’m not in a place where I can take the time to do that…
Tanks
[quote=324859:@Paulo Vargas]Hello, can someone tell me if I have a count of lines of code for a project in an automatic way, I need to see 3 projects of mine and I do not know how to do it.
Thank you so much ![/quote]
I’m always curious why people want to know this
Especially since the code you write IS only a portion of the work in any project
All the time you take in creating lay outs should count too but wont if you just count lines of code
not to mention, how many lines of code did you
- write
- rewrite
- delete
- refactor
Dead and Duplicate code might be more important,… the number of lines is not, as long as it gets the job done…
UNLESS you are PAID by the line, in which case your employer needs a reality check 
How do you count lines like:
[code]// Dim a FolderItem
Dim f As FolderItem
// Get a Reference to one of my nice item
f = SpecialFolders.Documents.Child(“My nice Folder”).Child(“My Sub Nice Folder”)_
.Child("One More Nice folder to get another line[/code]
Also, think that you can put a comment at the end of a line of code
You can write one liners all the time,
You can write useless lines and forget to remove them,
and so on.
You have to know that the code above is a fiction 
[quote=324959:@Norman Palardy]I’m always curious why people want to know this
Especially since the code you write IS only a portion of the work in any project
All the time you take in creating lay outs should count too but wont if you just count lines of code[/quote]
Ok, here we go into esoterica…
Over time, it is possible to generate projections of project schedule vs bug detection/fixing. Each team of coders will generate a typical number of errors per line of code, and rate of fixing will also become typical. These statistics cannot be accrued over the life of a single project but for long term projects the numbers can be surprisingly accurate.
For example, if the Xojo development team had (has?) low turnover, the number of severity one bugs found and fixed per release over the last 3-5 years analyzed against the lines of code new or changed in each release could project the likely number of similar severity bugs found and fixed in current development work and give a fair estimate of the time required to complete the coding and bug fixing.
I know it sounds like magic, or wishful thinking, but I’ve seen it work. Of course, that was on a project that spanned seven years, nine major releases, and a staff turnover of less than 4%. The final version (before the company was bought by IBM and the product killed) had a projected Sev1 bug count that was off but the actual count by 2 bugs, and a miss of the projected release data by 9 days. The projections were made 32 weeks before release.
Not esoterica
I’ve just not seen it be as useful or predictive as you have
The problem is… writing code is NOT like building a house…
[quote=324959:@Norman Palardy]I’m always curious why people want to know this
Especially since the code you write IS only a portion of the work in any project
All the time you take in creating lay outs should count too but wont if you just count lines of code[/quote]
Hello Norman,
In my case it is because my projects have grown a lot in functionality and I am "cleaning my codes" and I want to do the before and after comparison !This I would say is a “curiosity” more than a good measure
ie/ in a real simple case
if foo then
bar
end if if foo then barthe first is 3 lines the second 1 BUT which is “better” (and I guarantee you will get more than 2 answer despite there being 2 choices in style)
All it tells you is “there is less code” but nothing more and certainly no qualitative assessments
I like compact code, and one liners can be quite appropriate. In VB I used multiple sentences on one liners, like I do in JS.
JS code, like C, can become extremely verbose when splitting everything in different lines.
In Xojo, the level of abstraction tends to keep code compact.
Yes, I did not even think about this count to measure quality, but out of curiosity as to how much it would decrease in the end.
simply, the size of the compiled app gives you a good indicator of code quality…
I hope you meant ‘quantity’…
Quality works too… Look at how huge all of Microsoft’s programs are…
My “Statistics” script for Arbed does not simply count all lines but also tells you how much are comments and how much are empty.
no I really mean quality.
compile your app,
make some code rework, if it’s good and still does the same thing, the final app size will be smaller.
it’s the same if you count lines, you cannot count lines if you add functionnalities, you must stay on the same app functions.