# Thread: Lines of code complexity metric

1. ## Lines of code complexity metric

Hi,

does anyone have a proper definition of how to capture a lines of code complexity metric?

is it simply a case of counting the lines of code within a function / application?

Seems a bit useless to me given that a good programmer could write a function in ten lines, that a bad programmer could write in fifty.

how would this allow me predict how complex the code is or how long it would take to test it? [img]/images/graemlins/confused.gif[/img]

cheers

Andy

3. ## Re: Lines of code complexity metric

Hi - thanks for the reply.

Thats cyclomatic complexity which is based on flow control.

I'm talking about lines of code complexity which is white box.

apparently the number of lines of code a dev writes can be used to estimate how complex a piece of software is and how long it should take to test it.

i've read the LOC article on wiki - i just thought there was more to it.

4. ## Re: Lines of code complexity metric

<TBODY>
<TR>
<TD vAlign=top width="44%"><FONT face=Tahoma size=1>
<P align=center>Andy
</FONT></P></TD>
<TD vAlign=top width="56%"><FONT face=Tahoma size=1>
<P align=center>JakeBroke
</FONT></P></TD></TR>
<TR>
<TD vAlign=top width="44%"><FONT face=Tahoma size=2>

does anyone have a proper definition of how to capture a lines of code complexity metric?</FONT></P></TD>
<TD vAlign=top width="56%"><FONT face=Tahoma size=2>

I am not aware of anything related to that specifically. There used to be a DoD standard that basically stated any unit with more than 100 executable-when-compiled source statements should be regarded as too complex and should then be rewritten. The IEEE imposed a similar limit but at 200 lines. The difference betwixt the two standards is/was as follows. The IEEE permitted multiple exit points. The DoD standard permitted a single exit point only. "C" programmers were upset and threatened to speed global warming and create a huge demand for B Spears "music".</FONT></P></TD></TR>
<TR>
<TD vAlign=top width="44%"><FONT face=Tahoma size=2>

is it simply a case of counting the lines of code within a function / application?</FONT></P></TD>
<TD vAlign=top width="56%"><FONT face=Tahoma size=2>

See above.</FONT></P></TD></TR>
<TR>
<TD vAlign=top width="44%"><FONT face=Tahoma size=2>

Seems a bit useless to me given that a good programmer could write a function in ten lines, that a bad programmer could write in fifty.</FONT></P></TD>
<TD vAlign=top width="56%"><FONT face=Tahoma size=2>

That is of course debatable depending upon many factors such as self-documenting goals/standards, compiler robustness, maintainability, etc.</FONT></P></TD></TR>
<TR>
<TD vAlign=top width="44%"><FONT face=Tahoma size=2>

how would this allow me predict how complex the code is or how long it would take to test it? ...</P>

Thats cyclomatic complexity which is based on flow control. I'm talking about lines of code complexity which is white box.</FONT></P></TD>
<TD vAlign=top width="56%"><FONT face=Tahoma size=2>

Nonetheless, Cyclomatic Complexity is certainly a good measure.</FONT></P></TD></TR>
<TR>
<TD vAlign=top width="44%"><FONT face=Tahoma size=2>

apparently the number of lines of code a dev writes can be used to estimate how complex a piece of software is </FONT></P></TD>
<TD vAlign=top width="56%"><FONT face=Tahoma size=2>

I recommend Cyclomatic Complexity.</FONT></P></TD></TR>
<TR>
<TD vAlign=top width="44%"><FONT face=Tahoma size=2>

apparently the number of lines of code a dev writes can be used to estimate how long it should take to test it.</FONT></P></TD>
<TD vAlign=top width="56%"><FONT face=Tahoma size=2>

I suppose one could derive accurate estimates for unit and unit-integration testing, just using traditional estimating methods. For testing in the black or gray box domains, I would think this a huge challenge.</FONT></P></TD></TR></TBODY></TABLE>

5. ## Re: Lines of code complexity metric

i have a software testing pratitioners exam coming up and this is one of the questions in the practise paper which was not particularly well explained in the course notes.

6. ## Re: Lines of code complexity metric

Andy, do you mind sharing the examiner info (company)? Also, let us know how you do please. Good luck!

7. ## Re: Lines of code complexity metric

the examiner info as in who I went to organise the exam (ISEB - British Computer Society) or who provided the training (I bought two courses off net and obtained four practice exams).

8. ## Re: Lines of code complexity metric

@ Andy,

I would say it depends on the context &amp; on the programming language you choose.

There won't be common best practices and definitions that we can use all across the contexts.

Cyclomatic Complexity has been widely used to capture the complexity of the code what ever might be user programming language.

Do let us know if you come across some &amp; that will be a lesson to learn for most of us.

9. ## Re: Lines of code complexity metric

Hi Gandy,

I am late to the party and this slipped by. Jake and others have suggested a metric of McCabe's cyclomatic complexity which you correctly states is a measure of control flow through an algorithm. There are several complexity measures such as Halstead's complexity metric, fan in/fan out, etc.

However, I read your question as counting lines of code which is measured as KLOC (or thousand lines of code). You are also absolutely correct that a good programmer could write a function with ten and a not so good programmer could write the same function with 50 lines of code. So you ask how could LOC or KLOC be a useful measure?

The value of KLOC is valuable if we understand that defects in an algorithm are randomly distributed. (Forget the Pareto analysis stuff with regard to bug distribution...when a developer writes 100 lines of code, 80% of the bugs don't congregate in 20 lines of the code...that's a rediculous assertion.) So, if a non-proficient developer takes 5 times more lines of code to write the same function as a proficient developer then I might be able to predict a probability of 5 times more defects exist in those 50 lines of code as compared to the 10 lines of code in our example.

However, this is also all predicated on the fact that we also know the defect density ratio for each of the developers, and also the various complexity measures for the function, and the programming language used in the implementation as well is a factor (strongly typed vs. non-strongly typed languages).

Of course, you also have to know this is all theoretical and based on statistical probabilities.

10. ## Re: Lines of code complexity metric

[ QUOTE ]
(Forget the Pareto analysis stuff with regard to bug distribution...when a developer writes 100 lines of code, 80% of the bugs don't congregate in 20 lines of the code...that's a rediculous assertion.)

[/ QUOTE ]

I'm just going by intuition, but I don't think that assertion is ridiculous at all. Of course the hard part is that you have no idea ahead of time which 20% of the code has the bugs -- unless there's some heuristic way to judge, say because some piece of functionality is particularly tricky. So I'm not sure what the practical implications of this assessment are.

To my incomplete understanding, the "Pareto analysis stuff" is probably correct, but in no way undermines your point that defects tend to scale linearly with LOC.

Page 1 of 2 12 Last

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.