Prev: FAQ Topic - Internationalisation and Multinationalisation injavascript. (2010-03-23)
Next: HTML tags in textarea
From: Johannes Baagoe on 25 May 2010 22:26
Stefan Weiss :

> I've been using SLOCCount [0] since 2005, and it's a nice toy,

I didn't know its existence, thanks for pointing it out! Great fun.

> but it hasn't been maintained since its release, and it still ignores
> JS files, SQL stored procedures, and many others.

An `--addlang sql` option will add sql. `--addlangall` adds sql,
makefiles and html.

It should be easy to add support for .js files:
http://www.dwheeler.com/sloccount/sloccount.html#adding

> PS: Again, just in case: I only use SLOCCount for fun. I'm not taking
> the numbers seriously. I suppose I could try to impress clients with
> the $$ figures, but I'd consider that lying.

Quite. But it is fun to see how rich one would supposedly be, if
only one had the right mentality. My latest project is valued at
$ 4,721,012. (In order to figure out why a function suddenly became 25 %
slower after a functionally insignificant change, I used the gcc -S
option to produce intermediary asm files. They turn out to represent
133261 SLOC, 97.52% of the total.)

--
Johannes
From: Sean Kinsey on 26 May 2010 04:30
On May 26, 2:30 am, Stefan Weiss <krewech...(a)gmail.com> wrote:
> Does anybody here know of a tool which can count the number of source
> files and lines of code used in a project, and will parse JS files as
> well as the more commonly supported languages (C, C++, Java, Python,
> Perl, etc)? I've been using SLOCCount [0] since 2005, and it's a nice
> toy, but it hasn't been maintained since its release, and it still
> ignores JS files, SQL stored procedures, and many others. In some
> projects, these file types make up more than half of the code, so I'm
> looking for alternatives.
>
> Before anybody objects to the use of LOC as a code metric: yes, I'm
> fully aware that this approach is futile. A project with 1000 lines of
> PHP will have more than double the LOC when implemented in C, and only
> one line, or _maybe_ two lines, if written in Perl. Not to mention
> differences in coding style and all the other factors which can't be
> measured by counting lines (structure, comments, readability, copypasta,
> research, and so on). In the rare case where two projects are similar
> enough, the LOC count could theoretically be used to compare them, but
> that's about the limit of its usefulness.
>
> I'm not looking for accuracy or correctness here. I just like to see the
> numbers grow. I run SLOCCount about once a week, usually at the end of a
> long coding session, and it gives me a warm and fuzzy feeling before I
> go home. For example, the project I'm currently working on is a small
> web application, written from scratch. After 2 weeks, SLOCCount gives
> the following report:
>
> [snip details]
> Total Physical Source Lines of Code (SLOC)                = 4,673
> Development Effort Estimate, Person-Years (Person-Months) = 1.01 (12.11)
>  (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
> Schedule Estimate, Years (Months)                         = 0.54 (6.45)
>  (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
> Estimated Average Number of Developers (Effort/Schedule)  = 1.88
> Total Estimated Cost to Develop                           = $ 136,369
>  (average salary = $56,286/year, overhead = 2.40).
>
> I should probably adjust the model's parameters before running the tool,
> but since the amounts are pure fantasy anyway, I just run it with the
> defaults. There's no way that this little project is worth anywhere near
> $100k; it's not even in the same magnitude. Still, I like to see the
> numbers increasing. It's also interesting to see what percentage of the
> whole the different languages make up (I snipped this part).
>
> And that's the problem: the tool arrived at 4673 LOC, but completely
> ignored input like JS, SQL, and executable scripts without an extension;
> not to speak of CSS and HTML (which aren't programming languages, but do
> contribute to the overall effort).
>
> I've seen some other code analyzers mentioned [1], but most of them
> don't handle JS. The ones that do are too expensive to be used for fun
> [2]. If any of you have worked with similar tools, I'd be interested to
> hear about your experiences.
>
> [0]http://www.dwheeler.com/sloccount/
> [1]http://www.locmetrics.com/alternatives.html
> [2]http://www.jamesheiresconsulting.com/Order%20Form.htm
>
> PS: Again, just in case: I only use SLOCCount for fun. I'm not taking
> the numbers seriously. I suppose I could try to impress clients with the
> $$ figures, but I'd consider that lying.
>
> --
> stefan

Take a look at Ohcount (http://www.ohloh.net/p/ohcount), the tool used
by Ohloh.net
It works quite well
From: Thomas 'PointedEars' Lahn on 26 May 2010 04:57
Stefan Weiss wrote:

> nick wrote:
>> On May 25, 8:30 pm, Stefan Weiss <krewech...(a)gmail.com> wrote:
>>> Does anybody here know of a tool which can count the number of source
>>> files and lines of code used in a project [...]
>> I'd probably use some combination of `find` and `wc` for that... might
>> be worth looking into?
>
> I think you'd have to actually parse the source files. LOC counts
> usually don't include blank lines or comments.
> Removing comments from a JS file with grep/sed/awk/etc is not a trivial
> task. sed and awk are Turing complete, which means it must be possible,
> but I'd rather not try :)

grep(1) cannot help you there, sed(1) can. It depends on the comments,
though (code style is key). I am generating the "uncommented" versions of
my script files with sed(1), but it purposely leaves single-line comments in
unless they are on their own line.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: Stefan Weiss on 26 May 2010 06:57
On 26/05/10 04:19, nick wrote:
> On May 25, 9:45 pm, Stefan Weiss <krewech...(a)gmail.com> wrote:
>> I think you'd have to actually parse the source files. LOC counts
>> usually don't include blank lines or comments.
>> Removing comments from a JS file with grep/sed/awk/etc is not a trivial
>> task. sed and awk are Turing complete, which means it must be possible,
>> but I'd rather not try :)
>
> `cpp` will remove the comments... it leaves behind some other junk,
> but that's easily removed with sed.

Careful there. CPP doesn't know about regular expression literals.

$ cat test.js
var foo = /x\/*y/;
var bar = 42;
var baz = /xy*/;
$ cpp -P test.js


var foo = /x\ ;

I suppose it's possible, in theory, to write a parser using sed, as
Thomas suggested, but it would be either very complex, or unsafe.


--
stefan
From: Thomas 'PointedEars' Lahn on 26 May 2010 07:05
Stefan Weiss wrote:

> I suppose it's possible, in theory, to write a parser using sed, as
> Thomas suggested, but it would be either very complex, or unsafe.

WFM. In practice, automatically, as a post-commit hook. wc -l says 20 LOCs
(counting the empty ones ;-)).


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: FAQ Topic - Internationalisation and Multinationalisation injavascript. (2010-03-23)
Next: HTML tags in textarea