Re^2: Code Statements/Lines per Function Point

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

Comment on Re^2: Code Statements/Lines per Function Point Select or Download Code

Replies are listed 'Best First'.
Re^3: Code Statements/Lines per Function Point by hv (Prior) on Aug 25, 2004 at 12:04 UTC
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]
Re^3: Code Statements/Lines per Function Point by dragonchild (Archbishop) on Aug 25, 2004 at 12:09 UTC
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^4: Code Statements/Lines per Function Point by PerlingTheUK (Hermit) on Aug 25, 2004 at 12:38 UTC
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]
Re^5: Code Statements/Lines per Function Point by dragonchild (Archbishop) on Aug 25, 2004 at 13:30 UTC
Update: Anyone who understands function-points will realize from my post that I didn't. However, the point I'm making still has validity. You cannot take the same number of function-points and the cost/fp in language A and use them to estimate the total cost when implementing in language B. That's the point I didn't realize I was trying to make. It would be interesting, however, to see what the average cost/fp is in Perl as opposed to other languages, such as C. I don't know of any such project. hv's response to your post may have some useful info. However, I feel the need to correct a further misconception. The number of function-points will be lower in Perl than in most comparable languages. Let's take C, for example, and use a case that's heavily biased towards Perl - creating a linked list. In C, this would require a bunch of maintenance code dealing with pointer arithmetic and calls to malloc(), free(), and code to insert, delete, and a bunch of state information. In Perl, you use an array. The code provides the exact same functionality, but requires as few as 10% of the function-points in Perl as in C. Let's take another example that's heavily biased to Perl - parsing textfiles. Again, let's compare vs. C. In C, you have to open the file, allocate memory, use tok(), strcmp, and a bunch of other crazy stuff. When I used to do this, I had macros calling macros calling macros ... and it was still ugly. In Perl, you open the file, use a regex or two, add the values to an array of hashes, and be done with it. Again, we're talking about 90% fewer function-points in Perl as in C. You may think I'm picking on C cause it showcases Perl very nicely, but Pascal isn't much better. Java starts to compare well, but still comes up short. Frankly, Perl is simply more expressive than nearly any other language in common use. And, that doesn't even count the code that using CPAN provides. In other words, I don't think you're going to be able to take function-point counts from another language and have them be useful in estimating time to develop in Perl. ------ 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^6: Code Statements/Lines per Function Point by PerlingTheUK (Hermit) on Aug 25, 2004 at 14:16 UTC
Re^7: Code Statements/Lines per Function Point by dragonchild (Archbishop) on Aug 25, 2004 at 14:32 UTC