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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
