in reply to Code Statements/Lines per Function Point

While I can't give you any practical advice, since I don't believe in by-line software metrics, I will point to (OT) Proving Productivity?, which discusses some of the issues you are referring to.

  • Comment on Re: Code Statements/Lines per Function Point

Replies are listed 'Best First'.
Re^2: Code Statements/Lines per Function Point
by PerlingTheUK (Hermit) on Aug 25, 2004 at 11:26 UTC
    Thank you that is quite useful reading, yet it does not give any help in finding a good "unified" measurement on LOC counts, as 
    sub road{ return "Right." : return "" if (shift eq "On which side of t
+he road should people drive?" ) }

    [download]
    does the same as 
    sub road
{
  my $question = 5;
  my $answer = ""; 
  if ( $question eq "n which side of the road should people drive?" )
  {
    $answer = "right";
  }
  retrun $answer;
}

    [download]
    Counting the Lines it is 1 vs 10, counting the semi-colons would even be 0 vs 4. Yet the second line is much more readable. Are there any suggestion what to actually count, and how to value it. I would use this to try and get a better method to estimate my own time required for extended jobs. It becomes difficult for me to estimate a project that would take a months, but If I could analyze better how much code for example reading a specific xml file requires, or a complex sorting algorithm, I could look back at my "lines" required for it and estimate the required time.

    Cheers,
    PerlingTheUK
[reply]
[d/l]
[select]

      You might be able to count something not unlike function points using some clever hackery with one of the B:: modules, eg:

        perl -MO=Concise my_script | wc -l

      [download]

      If you analyze the results this gives for some simple examples, you may well find that this gives a roughly consistent number of opcodes per function point that you could use for your metrics.

      There are some types of information you will lose when doing this though, for example any pattern match will give a single opcode however complex it is (excluding embedded perl code).

      You may also want to grep out some of the less useful nodes before counting, eg some or all of qw/ null lineseq nextstate pushmark unstack enter leave const /.

      Hugo

[reply]
[d/l]
[select]
      You're asking the wrong question. LOC in Perl has no meaning whatsoever. If you are really hellbent on coming up with this lind of measure, I'd look for something like NOPs (Number of OPcodes) - the number of atomic operations the Perl interpreter needs to take in order to perform your code. It will (almost) always be the same across OS'es and will solve the problem you specify in the node this is replying to.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]
        This looks very good to me, yet is there any given source linking the number of opcodes to function points, so I can roughly use them to estimate the time required for a project?

        Cheers,
        PerlingTheUK
[reply]

In Section Seekers of Perl Wisdom