get an overview of all scripts (e.g total lines of all scripts) of a stack

Richard Gaskin ambassador at fourthworld.com
Thu Mar 14 11:10:36 EDT 2019


Mark Wieder wrote:

 > On 3/12/19 4:30 PM, Richard Gaskin via use-livecode wrote:
 >>
 >> At some point I'll roll project metrics into the Projects pane in
 >> devolution, but truth be told I have a note about that right in the
 >> very place I'll be adding it, and no one's asked about it.
 >
 > Well, I'll ask now. There's only a vague reference to metrics in
 > devolution, and you really have to know it's there in order to find it
 > (starting to sound familiar...?) Anyway, I got into a long discussion
 > at SCaLE about the drawbacks of most metrics, but Cyclomatic
 > Complexity would give very useful insight into the overall health of a
 > project.

Thanks.  I'll count that as a "Yes, do it" vote. :)

I don't mind taking the time to write metrics tools (kinda enjoy it), 
but having done that sort of thing for decades in every xTalk I've used 
I've had a difficult time finding true value-add uses-cases for them 
(perhaps my experience is similar to your discussion at the Expo).

So when someone asks for things like number of script lines, or number 
of objects, or anything else, I always ask "Why?"

And I never get a reply. Ever. In the last 10 years I've been asking.

Which has so far served as an indicator of the actual value-add. ;)

So dear readers, please understand that I'm rather eager to produce 
exactly what you're looking for, if I can learn more specifically what 
it is you want and how it helps your development process.

Consider this an open invitation to discuss the business case for 
project metrics, and which ones are especially valuable to your work and 
which one's aren't.



PS, in reply to an earlier reader who hadn't yet used Cyclomatic 
Complexity: Complexity measurements help us see the difference between 
simple code and complicated code.  Not that complicated necessarily 
means spaghetti, but number of script lines alone don't tell us much 
about the difficulty of maintaining code.  A long script of simple 
statements may pose a smaller maintenance cost than a shorter script 
chock full o' "send in <time>" or other things that affect logic flow 
and thus have a correlation with debugging/maintenance costs.


PPS: I've sketched out some ideas a while back for a sort of "Code 
Doctor", which would examine scripts and make suggestions for possible 
optimizations.  This is not a small task, but could start modestly with 
a reasonably extensible framework we could all build on from there. 
Given the number of hours required away from client work, I'm unlikely 
to finish that in the forseeable future, but if this is of interest I 
would welcome a discussion of crowd-sourcing any sufficiently-attractive 
tools for streamlining professional development.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list