PerlingTheUK has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,
I am currently reviewing a bit of existing source code and have to estimate the possible cost of redevelopment, compared to the cost of extending existing Delphi/Pascal sources.
I am trying to value these functionality with Models like COCOMOII. one of the best sources available online is Cost Estimation, Metrics and Models.
To evaluate the required effort the advanced techniques not only require the number of code lines, but also the number of lines per function point.
I would like to be able to compare these results to my own software development in Perl. This leads me to some questions:
  1. What value is considered to be the number of lines of a function point in Perl?
  2. How would you defined this number in Perl? I am fairly spacious in most my sources, each curly loop brace gets its line on its own, this would easily extend the number of lines by 5 to 10 percent. ALternatively I could count the number of ";", yet there do not need to be any semi-colons in some lines that are fairly complex. And then a for loop has three of them. Is there any definition around?
  3. You might have considered writing me that an extended regexp can do as much as 30 lines of code without any regexp, so here I come and ask if there are "special" lines of code that take more time. I guess in five Perl lines you can open a file read its contents reformat them completely and write them to another format. This would in my understanding make 0.4 function points per line. (Delphi has only one per every ninety lines)
  4. Alternative methods. Are there any? Are they Perl exclusive? How do you personally estimate the time programming some script takes you.
  5. More in general, are there any good sources about software engineering in Perl? It is a slighlty uncommon languange to use for extended professional standalone programmes, but it is my first choice to C and JAVA and I would like to find arguments for it and help more specific to software engineering.
As for my previous experience estimating time valuyes, I always used to only add on fairly small portions of code to an exsisting tool, or write rather small scripts from scratch. In these cases I had a fairly exact estimation of how much time it would take me by just thinking about how to write the tool. I usually ended up to be able to estimate this amount of time to about two hours correctly for a problem that took a week of coding. I then added 50% time for debugging and 50% for wrong user-specifications. Debugging usually required ten minutes unless and that happens a bit too often the user specifications were too unspecific or wrong. Yet still this was a good estimate that was within 15% boundaries.

Cheers,
PerlingTheUK
  • Comment on Code Statements/Lines per Function Point

Replies are listed 'Best First'.
Re: Code Statements/Lines per Function Point
by rnahi (Curate) on Aug 25, 2004 at 10:29 UTC

    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.

[reply]
      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]
Re: Code Statements/Lines per Function Point
by TrekNoid (Pilgrim) on Aug 25, 2004 at 14:21 UTC
    Here's a few things I ran across

    Devel-Cover

    MetricsPaper.pdf

    (This one is useful in that you might be able to contact the author and see the metrics they used.)

    MetricsComparison.pdf

    (has some information on how they used metrics to compare several languages)

    I don't know if that gets you what you want, but hopefully it helps

    Trek

    Edit: Used titles to shorter the URLs

[reply]
      Thank you, especially the last link, can be of huge service for explaining why I want to do dome upcoming job in Perl instead of C++ or Java.

      Cheers,
      PerlingTheUK
[reply]
Re: Code Statements/Lines per Function Point
by tilly (Archbishop) on Aug 25, 2004 at 18:03 UTC
    I'd suggest that you try implementing a couple of sample projects in Perl, and come up with estimates for how productive you are in Perl.

    How productive Perl is per line depends on your coding style, knowledge of techniques, how well a problem fits Perl's strengths, whether there is an appropriate CPAN module, etc. It is extremely variable. But the variability will go down a lot if you measure one person, with the kinds of projects that that person tends to do. Furthermore if you're the person measured, then the estimate that you come up with is going to apply more directly to your project.

[reply]

Back to Seekers of Perl Wisdom