Counting lines of code

Hi,

what is the easiest way of counting LOC of my project?

Thanks Roland

On Jan 30, 2008 10:28 AM,  <[hidden email]> wrote:

> what is the easiest way of counting LOC of my project?

Get somebody else to do it.

Cheers!

--Tom Phoenix

On Jan 30, 2008 10:28 AM,  <[hidden email]> wrote:

> what is the easiest way of counting LOC of my project?

Okay, more seriously. Step one: File it out. Step two: Figure out a
way to count the LOC in a text file.

But even more seriously, what's the point of counting lines of code?
If you were painting a portrait, would you count the brushstrokes?
Lines of code as a metric correlates poorly with things that actually
matter, like code quality and completeness. What are you *really*
trying to measure?

Cheers!

--Tom Phoenix

On 30-Jan-08, at 10:50 AM, Tom Phoenix wrote:

> On Jan 30, 2008 10:28 AM,  <[hidden email]> wrote:
>
>> what is the easiest way of counting LOC of my project?
>
> Get somebody else to do it.
And more to the point (unless you need it for some printing out type  
of reason) don't bother. LOC was never a useful measure of anything in  
software and is utterly meaningless in Smalltalk. Some of my most  
productive days have had a LOC count of negative a small number.  
Sometimes the best solution to a problem is to remove code, not add it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Dopeler effect (n): The tendency of stupid ideas to seem smarter when  
they come at you rapidly.

I used this some time ago and it worked. Hope it helps...

linesOfCodeOf: aSetOfClasses
| loc |
loc := 0.
aSetOfClasses do: [ : aClass |
    aClass class methodsDo: [ : aCompiledMethod |
        loc := loc + aCompiledMethod linesOfCode.
    ].   
    aClass methodsDo: [ :aCompiledMethod |
        loc := loc + aCompiledMethod linesOfCode.
    ].
].
^ loc

Now, you only need to know how to get what the classes of a project are.
Regards
Alejandro

On Jan 30, 2008 5:02 PM, tim Rowledge - [hidden email]

> And more to the point (unless you need it for some printing out type
> of reason) don't bother. LOC was never a useful measure of anything in
> software and is utterly meaningless in Smalltalk. Some of my most
> productive days have had a LOC count of negative a small number.
> Sometimes the best solution to a problem is to remove code, not add it.

Yes, I know, I know. Look, I don't want to start a long  discussion on
the usefulness(or lack thereof) of couting LOCs. I just want to know
if there is a simple way to count it. If not, any ideas of how this
should be implemented in a simple way?

Peace, Roland

PS: Sorry, I couldn't resist, but regarding your negative LOC example,
possibly you wasted time on a previous day implementing something in a
wrong or too complex way.  This information could be quite meaningful
and important.

On 1/30/08, Alejandro Gonzalez <[hidden email]> wrote:

> Now, you only need to know how to get what the classes of a project are.

(PackageInfo named: 'SomeCategory') classes

This should work:

(PackageInfo named: 'SomeCategory') classesAndMetaClasses detectSum:
[:ea | ea linesOfCode]

On Jan 30, 2008 8:02 PM, tim Rowledge <[hidden email]> wrote:
>
> And more to the point (unless you need it for some printing out type
> of reason) don't bother. LOC was never a useful measure of anything in
> software and is utterly meaningless in Smalltalk.

I think Fred Brooks would disagree, though you are correct if you mean
that the LOC one types in a day isn't a useful measure of what they've
accomplished.  But how many LOC your project has associated with it is
a good way to determine the cost of the project and pain of
maintenance.  Any time you can reduce overall LOC while keeping all
functionality that's a gain.

> Some of my most
> productive days have had a LOC count of negative a small number.
> Sometimes the best solution to a problem is to remove code, not add it.

Exactly.

On 30-Jan-08, at 11:16 AM, [hidden email] wrote:
>
>
> PS: Sorry, I couldn't resist, but regarding your negative LOC example,
> possibly you wasted time on a previous day implementing something in a
> wrong or too complex way.  This information could be quite meaningful
> and important.

What!!! How could you suggest such a thing! Just ask anyone; I *never*  
make miskates.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: JSP: Jump on Sexy Programmer

On Jan 30, 2008 8:44 PM, tim Rowledge <[hidden email]> wrote:
>
> What!!! How could you suggest such a thing! Just ask anyone; I *never*
> make miskates.

I was pretty surprised! :)

On Jan 30, 2008 5:00 PM, Tom Phoenix - [hidden email]

> > what is the easiest way of counting LOC of my project?
>
>
> But even more seriously, what's the point of counting lines of code?
> If you were painting a portrait, would you count the brushstrokes?
> Lines of code as a metric correlates poorly with things that actually
> matter, like code quality and completeness. What are you *really*
> trying to measure?

I'm trying to measure my own productivity.

What's the point of counting transistors in chips?

On Jan 30, 2008 5:00 PM, Tom Phoenix - [hidden email] > Lines of
code as a metric correlates poorly with things that actually
> matter, like code quality and completeness. What are you *really*

What do you mean with "completeness"?

[hidden email] writes:
Well how productive is it to remove lines of code? How is that
measured? Not that I'm against it, but it just looks easy on the
surface. You have take into acount
1) written stuff
2) rewriten stuff
3) removed stuff
4) generated stuff
5) addWhatYouLike ;-)

Just a small remark, there do exist books about it from Humpreys what
he named
the personal software process the title of the book
is a discipline for software engineering.

It's really tough and chalenging, it covers a lot but still there are
problems, e.g my working styling is that I write a bit then I compile
it (if need should be) corrct typos and then I try to write a test or
step through it. How should I time this, is steppign through code
development time?, maintenance time or really debugging time. It's
IMHO development time, but it's not covered and how am I supposed to
count typos? Humphreys counts every typos as bug and so I would have a
very hight bug count. What is hard is finding out if you SLOC does not
have changed because you have just rewritten a few
things. Unfortunatly up to day I really do not know any good way on
judging about programming, even if code "works" I argue that things
could be "improved"

However I think for a starting point the posted things will help a
bit.
>
> What's the point of counting transistors in chips?
I think you can not compare it that way, because many LOCS do not
"automatically" mean much functionality. Just imagine how find all the
code generats have to be judged then ;-)

Please don't get me right, I do not say it's worthless, but difficult
and unfortunatly I do not know if this difficult means. You can get
something out of it or not. I think in the end one just can get near
something by statistical means, but well you know the saying about
lies and statistics ;-)

Regards
Friedrich

On Jan 30, 2008 8:27 PM,  <[hidden email]> wrote:
> On Jan 30, 2008 5:00 PM, Tom Phoenix - [hidden email] > Lines of
> code as a metric correlates poorly with things that actually
> > matter, like code quality and completeness. What are you *really*
>
> What do you mean with "completeness"?

"Completeness" means that the code accomplishes everything it sets out
to do. For example, a test suite isn't complete until it tests (at
least) every method in the classes it covers.

There's no one way of measuring programmer productivity, but LoC is an
especially crooked yardstick. Some proponents of test-driven
development suggest you count "number of tests written" and "number of
tests passed". Compared to LoC, those numbers are arguably relevant to
producing good software; so you'll have an excuse if you feel that you
must have something to count.

Cheers!

--Tom Phoenix