Software code metrics
Upcoming SlideShare
Loading in...5
×
 

Software code metrics

on

  • 1,566 views

The article describes 7 types of metrics and more than 50 their representatives, provides a detailed description and calculation algorithms used. It also touches upon the role of metrics in software ...

The article describes 7 types of metrics and more than 50 their representatives, provides a detailed description and calculation algorithms used. It also touches upon the role of metrics in software development.

Statistics

Views

Total Views
1,566
Views on SlideShare
1,566
Embed Views
0

Actions

Likes
0
Downloads
49
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software code metrics Software code metrics Document Transcript

  • Software code metricsAuthor: Anton MilutinDate: 20.07.2009AbstractThe article describes 7 types of metrics and more than 50 their representatives, provides a detaileddescription and calculation algorithms used. It also touches upon the role of metrics in softwaredevelopment.IntroductionThe article is the first stage of work carried out by OOO "Program Verification System" in the sphere ofcreating new specialized tools for calculating metrics [1]. It is a review of the existing metrics which willhelp you better understand how to solve some tasks. We are planning to develop a methodology ofestimating complexity of porting software on other platforms and also of paralleling a program code.This sphere is development of PVS-Studio products abilities not simply as a static analyzer but as a toolfor prognosing man-hours for programmers when mastering 64-bit systems and adapting algorithms tomulti-core systems.This article describes a great range of software metrics. Naturally, it is unreasonable to describe all theexisting metrics, because most of them are never used in practice due either to impossibility of using theresults, or impossibility of automating calculations, or specialized character of these metrics. But thereare metrics which are used rather frequently and it is these metrics that are reviewed further.In general, using metrics allows managers of projects and businesses to estimate complexity of a projectalready developed or even only being developed and to estimate the scope of work, stylistics of aprogram being developed and efforts of every developer participating in creation of a particularsolution. However, metrics can only serve as recommendations, one cannot rely fully on them for whendeveloping software, programmers try to minimize or maximize this or that aspect of their program andcan refer to various tricks up to reducing efficiency of the programs operation. Besides, if, for example,a programmer has written a few code lines or made some structure alterations it does not mean that hehas done nothing, but it can mean that a program defect was too difficult to detect. The last problem,however, can be partly solved when using complexity metrics as it is more difficult to find an error in amore complex program.1. Quantitative metricsFirst of all, we should consider quantitative characteristics of program source code (because they aresimple). The simplest metric is the number of code lines (SLOC). This metric has been originallydeveloped to estimate man-hours for a project. However, for the same functionality both can be splitinto several lines or written into one line, this metric is nearly impossible to use when dealing withlanguages in which you can write more than one command in one line. Thats why we distinguish logicaland physical code lines. Logical code lines are the number of a programs commands. This variant of
  • description has its disadvantages because it greatly depends on the programming language and stylebeing used [2].Besides SLOC, there are some other quantitative characteristics: • the number of empty lines, • the number of comments, • percent of comments (ratio of the number of lines containing comments to the general number of lines represented in percent), • the average number of lines for functions (classes, files), • the average number of lines containing source code for functions (classes, files), • the average number of lines for modules.Sometimes estimate of a programs stylistics (F) is distinguished separately. It consists in splitting aprogram into n equal fragments and evaluating each fragment by the formula Fi = SIGN (Ncom.i / Ni -0,1), where Ncom.i is the number of comments in the i fragment, Ni is the general number of code linesin i fragment. The general estimate for the whole program will be evaluated in the following way: F =SUMFi. [2]Besides, Holsteads metrics are also referred to the group of metrics based on calculation of some unitsin the program code [3]. These metrics are based on the following indices:n1 - the number of unique operators of a program including separation symbols, names of proceduresand operators (operator dictionary),n2 - the number of unique operands of a program (operand dictionary),N1 - the general number of operators in a program,N2 - the general number of operand in a program,n1 - a theoretical number of unique operators,n2 - a theoretical number of unique operands.Taking into consideration the denotations introduced, we can estimate:n=n1+n2 - the programs dictionary,N=N1+N2 - the programs length,N=n1+n2 - the programs theoretical dictionary,N= n1*log2(n1) + n2*log2(n2) - a theoretical length of the program (for programs which are stylisticallycorrect, deviation of N from N does not exceed 10%)V=N*log2n - the programs size,V=N*log2n - a theoretical size of the program where n* is a theoretical dictionary of the program.L=V/V - programming quality level, for an ideal program L=1
  • L= (2 n2)/ (n1*N2) - programming quality level based only on the parameters of a real program withouttaking into consideration theoretical parameters,EC=V/(L)2 - the programs understanding complexity,D=1/ L - labor-intensiveness of the programs coding,Y = V/ D2 - expression language levelI=V/D - information content of the program; this characteristic allows you to estimate intellectual effortson creation of the programE=N * log2(n/L) - estimate of necessary intellectual efforts when developing the program characterizingthe number of necessary elementary solutions when writing the programWhen using Holsteads metrics, disadvantages relating to writing one and the same functionality by adifferent number of lines and operators, are partly made up.One more type of software metrics relating to quantitative metrics is Jilbs metrics. They estimate thecomplexity of software on the basis of saturation of a program with conditional operators or loopoperators. Despite its simplicity, this metric shows rather well the complexity of writing andunderstanding a program; and when adding such an index as the maximum level of nesting conditionaland loop operators, efficiency of this metric increases quite significantly.2. Metrics of program control flow complexityThe next large class of metrics based not on quantitative indices but on analysis of the control graph ofthe program is called metrics of program control flow complexity.Before we describe the metrics themselves, we will describe the control graph of a program and meansof building it for better understanding.Let we have a program. We build an oriented graph for this program containing only one input and oneoutput, the nodes of the graph correlate with those code sections of the program which have onlysequential calculations and no branch and loop operators, and the arcs correlate with passages fromblock to block and branches of program execution. The condition of building this graph is that each nodecan be accessed from the initial one and the final node can be accessed from any other node [4].The most popular estimate based on analysis of the built graph is cyclomatic complexity of the program(McCabes cyclomatic number) [4]. It is evaluated by the formula V(G)=e - n + 2p, where e is the numberof arcs, n is the number of nodes and p is the number of cohesion components. The number of cohesioncomponents of the graph can be considered as the number of arcs which we need to add into the graphto turn it into a strongly connected graph. A strongly connected graph is a graph whose two any nodesare mutually accessible. For the graphs of correct programs, i.e. graphs which have no sectionsinaccessible from the input point and dangling input and output points, a strongly connected graph isusually built by linking the node representing the end of the program and the node representing theinput into the program with an arc. Essentially, V(G) evaluates the number of linearly independent loopsin a strongly connected graph. So, p=1 in correctly written programs and thats why the formula ofestimating cyclomatic complexity turns into:V(G)=e - n + 2.
  • Unfortunately, this estimate cannot distinguish cyclomatic and conditional constructions. One moreessential disadvantage of this approach is that programs represented by the same graphs can havepredicates of absolutely different complexities (a predicate is a logical expression containing at least onevariable).To correct this defect G. Mayers developed a new methodology. He suggested to take as an estimatethe interval (this estimate is also called an interval estimate) [V(G),V(G)+h], where h equals zero forsimple predicates and n-1 for n-argument ones. This method allows you to distinguish betweenpredicates which differ in complexity but it is used very rarely in practice.There is one more modification of McCabes method - Hansens method. In this case, the measure of aprograms complexity is represented by a pair (cyclomatic complexity, the number of operators). Theadvantage of this measure is its sensibility to softwares structuring.Chens topological measure expresses a programs complexity through the number of intersections ofbounds between the fields formed by the programs graph. This approach can be used only in case ofstructured programs allowing only sequential connection of control constructions. In case ofunstructured programs, Chens measure greatly depends on conditional and non-conditional transfers.In this case we can define the high bound and the low bound of the measure. The high bound is m+1,where m is the number of logical operators mutually nested. The low bound equals 2. When the controlgraph of the program has only one cohesion component, Chens measure coincides with McCabescyclomatic measure.To continue the topic of analysis of a programs control graph we can mention one more subgroup ofmetrics - Harrisons metrics and Mayjeals metrics.These measures take into account the programs nesting and length levels.Each node is assigned its complexity in accordance with the operator it represents. This initialcomplexity of a node can be estimated by any method including Holsteads metrics. For each predicatenode lets assign a subgraph spawned by the nodes serving as the ends of the arcs stretching from it andalso by the nodes accessible from each of these nodes (the low bound of the subgraph) and the nodeslying in the paths between the predicate node and some low bound. This subgraph is called theinfluence area of the predicate node.Reduced complexity of the predicate node is a sum of initial and reduced complexities of the nodesincluded into its influence area plus initial complexity of the predicate node itself.Functional measure (SCOPE) of a program is a sum of reduced complexities of all the nodes of thecontrol graph.Functional relation (SCORT) is the ratio of the number of nodes in the control graph to its functionalcomplexity, terminal nodes being excluded from the number of nodes.SCORT can take different values for graphs with the same cyclomatic number.Pivovarovskiys metric is another modification of cyclomatic complexitys measure. It allows you to tracedifferences not only between sequential and nested control constructions but between structured andnon-structured programs as well. It is expressed by the relation N(G) = v *(G) + SUMPi , where v *(G) is amodified cyclomatic complexity calculated in the same way as V(G) but with the difference that CASEoperator with n outputs is considered to be one logical operator and not n-1operators.
  • Pi is the nesting level of i predicate node. To estimate the nesting level of predicate nodes the numberof "influence areas" is used. By a nesting level we understand the number of all the "influence areas" ofpredicates which either are fully included into the area of the node under consideration or intersectwith it. The nesting level increases due to nesting of "influence areas" and not predicates themselves.Pivovarovskiys measure increases when passing on from sequential programs to nested and further onto non-structured ones. It is a great advantage of this measure over many other measures of this group.Woodwords measure is the number of intersections of the control graphs arcs. As such intersectionsshould not be in a well structured program, this metric is used mostly in weakly structured languages(Assembler, Fortran). An intersection point appears when control excesses the limits of the two nodesserving as sequential operators.Boundary value method is also based on analysis of a programs control graph. To define this method weneed to introduce some additional notions.Let G be the control graph of a program with a single initial and a single final nodes.In this graph, the number of incoming arcs is called a negative degree of the node and the number ofoutgoing arcs - a positive degree of the node. So the set of the graphs nodes can be divided into twogroups: nodes whose positive degree <=1 and nodes whose positive degree >=2.The nodes of the first group are called receiving nodes and the nodes of the second - sampling nodes.Each receiving node has a reduced complexity equaling 1 except for the final node whose reducedcomplexity equals 0. Reduced complexities of all the nodes of G graph are summed and present theabsolute boundary complexity of the program. After that the relative boundary complexity is estimated:S0=1-(v-1)/Sa,where S0 is the relative boundary complexity of the program, Sa is the absolute boundary complexity ofthe program and v is the general number of the nodes of the programs graph.There is also Shneidewinds metric expressed through the number of possible paths in the control graph.3. Metrics of data control flows complexityThe next type of metrics is metrics of data control flows complexity.Chepins metric: this method consists in estimating the information strength of a separate programmodule with the help of examining the way the variables from the input-output list are used.The whole set of variables comprising the input-output list is divided into 4 functional groups:1. P - input variables for calculations and output,2. M - modified (or created inside the program) variables,3. C - variables participating in controlling the program modules operation (control variables),4. T - variables not used in the program ("parasite" variables).As each variable can simultaneously perform several functions we should consider it in eachcorresponding functional group.
  • Chepins metrics:Q = a1*P + a2*M + a3*C + a4*T,where a1, a2, a3, a4 are weighting ratios.Weighting ratios are used to reflect different influence of each functional group on the programscomplexity. As the metrics author supposes, the functional group C has the largest weight (3) because itinfluences the control flow of the program. Weighting ratios of the other groups are arranged as follows:a1=1, a2=2, a4=0.5. The weighting ratio of T group does not equal 0 as "parasite" variables do notincrease the complexity of the programs data flow but sometimes make it more difficult to understand.Taking into account weighting ratios:Q = P + 2M + 3C + 0.5TSpan metric is based on localization of data calls inside each program section. Span is the number ofstatements containing this identifier between its first and last appearances in the program text.Consequently, the identifier that appeared n times has span n-1. The larger the span, the more complextesting and debugging.One more metric considering the complexity of data flow is metrics binding complexity of programs withcalls to global variables.The pair "module - global variable" is identified as (p,r), where p is a module possessing access to theglobal variable r. Depending on presence or absence of a real call to r variable in the program there aretwo types of pairs "module - global variable": actual and possible. A possible call to r with the help of pshows that the existence domain of r includes p.This characteristic is identified as Aup and shows how many times Up modules had actual access toglobal variables while Pup number shows how many times they could get this access.Ratio of the number of actual calls to possible ones is estimated in this way:Rup = Aup/Pup.This formula shows an approximate probability of linking of an arbitrary module to an arbitrary globalvariable. Evidently, the higher this probability, the higher the probability of "unauthorized" change ofsome variable what can make it more difficult to modify the program.On the basis of the concept of information flows Kafurs measure has been created. To use this measurewe should introduce the notions of local and global flows: the local information flow from A to B existsif:1. A module calls B module (direct local flow)2. B module calls A module and A returns into B the value which is used in B (indirect local flow)3. C module calls modules A and B and transfers the result of A modules execution into B.Further, we should introduce the notion of a global information flow: a global information flow from Ainto B through the global data structure D exists if A module puts information into D and B module usesinformation from D.
  • On the basis of these notions I value is introduced - it is information complexity of a procedure:I = length * (fan_in * fan_out)2Here:length is complexity of the procedures text (it is measured with the help of some size metrics likeHolsteads, McCabes, LOC metrics etc)fan_in is the number of local flows incoming into the procedure plus the number of data structures fromwhich the procedure gets informationfan_out is the number of local flows outgoing from the procedure plus the number of data structureswhich are updated by the procedureWe can define information complexity of a module as a sum of information complexities of theprocedures included into it.The next step is to consider information complexity of a module in relation to some data structure.Measure of information complexity of a module in relation to a data structure:J = W * R + W * RW + RW *R + RW * (RW - 1)W is the number of subprocedures which only update the data structure;R only read information from the data structure;RW both read and update information in the data structure.One more measure of this group is Oviedos measure. It consists in splitting the program into linear non-intersecting sections - rays of operators which comprise the control graph of the program.The author of the metrics proceeds from the following suggestions: for a programmer it is easier to findthe relation between defining and using occurrences of a variable than between the rays; the number ofdefining occurrences in each ray is more important than the general number of using occurrences ofvariables in each ray.Lets define by R(i) a set of defining occurrences of variables which are situated within the range of i ray(a defining occurrence of a variable is considered to be within the range of a ray if the variable is eitherlocal in it and has a defining occurrence or has a defining occurrence in some previous ray and no localpath definition). Lets define by V(i) a set of variables whose using occurrences are already presented in iray. Then the complexity measure of i ray is defined in this way:DF(i)=SUM(DEF(vj)), j=i...||V(i)||where DEF(vj) is the number of defining occurrences of vj variable from the set R(i), and ||V(i)|| is thepotency of V(i) set.4. Metrics of control flow and data flows complexityThe fourth class of metrics is metrics close both to the class of quantitative metrics, metrics of programcontrol flows complexity and the class of metrics of data flow complexity (actually, this class of metricsand the class of program control flows metrics refer to the same class - topological metrics, but it isreasonable to distinguish them here to make it clearer for understanding). This class of metrics
  • estimates complexity of a programs structure both on the basis of quantitative calculations and analysisof control structures.The first such metric is testing M-measure [5]. Testing M-measure is a complexity measure meeting thefollowing conditions:The measure increases together with the nesting level and considers the length of the program. Themeasure based on regular nestings is close to the testing measure. This measure of program complexityconsists in calculating the total number of symbols (operands, operators, brackets) in a regularexpression with the minimum number of brackets defining the programs control graph. All themeasures of this group are sensible to the nesting level of control constructions and programs length.But estimate becomes more labor-intensive.Besides, program modules cohesion also serves as a measure of software quality [6]. This measurecannot be expressed numerically. The types of module cohesion:Data cohesion - modules interact through parameter transfer and each parameter is an elementaryinformation object. This is the most preferable type of cohesion.Data structure cohesion - one module sends a composite information object (a structure) to the otherfor the purpose of data transfer.Control cohesion - one module sends an information object to the other - a flag intended for controllingits inner logic.The common coupling of modules takes place when they refer to one and the same area of global data.Common coupling is not desirable because, firstly, an error in the module using the global area canoccur unexpectedly in any other module; secondly, such programs are difficult to understand for it isdifficult for a programmer to find out what data exactly are used by a particular module.Content cohesion - one of the modules refers inside the other. This is an illegal cohesion for itcontradicts the principle of modularity, i.e. presentation of a module as a blackbox.External cohesion - two modules use external data, for example a communication protocol.Message cohesion - the loosest type of cohesion: the modules are not connected directly but interactthrough messages having no parameters.Absence of cohesion - the modules do not interact.Subclass cohesion - a relation between the parent class and the descendant class, the descendant isrelated to the parent while the parent is not related to the descendant.Time cohesion - two actions are grouped in one module only because they take place simultaneouslydue to some circumstances.One more measure concerning stability of a module is Kolofellos measure [7]. It can be defined as thenumber of changes we must introduce into the modules different from the module whose stability isbeing checked, and the changes must concern the module being checked.The next metric of this class is McCloores metric. There are three steps of estimating this metric:
  • 1. For each control variable i the value of its complexity function is calculated by this formula: C(i) = (D(i)* J(i))/n,where D(i) is the value estimating the influence area of i variable. J(i) is a measure of complexity ofmodules interaction through i variable, n is the number of separate modules in the partitioning scheme.2. For all the modules included into the partitioning area the values of their complexity function M(P) isestimated by the formula M(P) = fp * X(P) + gp * Y(P)where fp and gp are correspondingly the numbers of modules directly preceding or directly following Pmodule and X(P) is the complexity of addressing to P module,Y(P) is complexity of control of calling other modules from P module.3. General complexity of MP hierarchical partitioning scheme of dividing a program into modules isdefined by the formula:MP = SUM(M(P)) by all the possible values of P, i.e. modules of the program.This metric is meant for programs which are well structured and composed from hierarchical modulesdefining functional specification and control structure. It is also supposed that each module have oneinput point and one output point, the module performs only one function and module call is performedin accordance with the hierarchical control system which defines relation of the call at the set of theprogram modules.There is also a metric based on information concept - Berlingers metric [8]. Complexity measure isestimated in this way: M=SUMfi*log2pi, where fi is the frequency of i symbols appearance, pi is theprobability of its appearance.The disadvantage of this metric is that a program containing many unique symbols but in a smallamount will be of the same complexity as a program containing few unique symbols but in a largeramount.5. Object-oriented metricsDue to development of object-oriented programming languages a new class of metrics has appeared.They are correspondingly called object-oriented metrics. The most frequently used metrics in this groupare sets of Martins metrics and Chidamber and Kemerers metrics. Lets study the first subgroup.Before we discuss Martins metrics we need to introduce the notion of a class category [9]. Actually, aclass can be rather rarely used again separately from the other classes. Nearly every class has a group ofclasses with which it cooperates and from which it cannot be easily separated. To use such classes onceagain you need to use the whole class group. Such a class group is strongly connected and is called aclass category. A class category exists in the following conditions:The classes within the class category are closed to any changes all together. It means that if one classchanges, all the other classes in this category are likely to change too. If any of the classes is open tosome changes all of them are open to these changes as well.The classes in the category are used again only together. They are so much interdependent that cannotbe separated. Thus, if you try to use one class in the category once again, all the other classes must beused together with it.
  • The classes in a category share some common function and achieve some common goal.Responsibility, independence and stability of a category can be estimated by calculating dependenciesinteracting with this category. There are three metrics:1. Ca :Centripetal cohesion. The number of classes outside this category which depend on the classesinside this category.2. Ce: Centrifugal cohesion. The number of classes inside this category which depend on the classesoutside this category.3. I: Instability: I = Ce / (Ca+Ce). This metric has the range [0,1].I = 0 denotes a maximum stable category.I = 1 denotes a maximum instable category.You can define the metric estimating abstractness of a category (a category is abstract if it is ratherflexible and can be easily extended) in the following way:A: Abstractness: A = nA / nAll.nA - number_of_abstract_classes_in_the_category.nAll - general number_of_classes_in_the_category.Values of this metrics vary within the range [0,1].0 = the category is absolutely concrete,1 = the category is absolutely abstract.Now on the basis of Martins metrics described above we can build a graph reflecting dependencebetween abstractness and instability. If we draw a straight line on it defined by the formula I+A=1, therewill be the categories lying on this line which have the best balance between abstractness andinstability. This straight line is called the main sequence.Further, we can introduce two more metrics:Main sequence distance: D=|(A+I-1)/sqrt(2)|Main sequence normalized distance: Dn=|A+I-2|It is true nearly for any category that the nearer they are to the main sequence, the better.The next subgroup of metrics is Chidamber and Kemerers metrics [10]. These metrics are based onanalysis of methods of a class, an inheritance tree etc.WMC (Weighted methods per class), total complexity of all the class methods: WMC=SUMci, i=1...n,where ci is complexity of i method estimated by any metrics (Holsteads metrics etc, depending on thecriteria we are interested in). If all the methods have the same complexity, WMC=n.DIT (Depth of Inheritance tree) - the depth of the inheritance tree (the longest path through the classhierarchy from the parent class to the class observed). The longer the path, the better, for abstractness
  • of data increases together with the depth while saturation of the class with methods decreases, but itgets very difficult to understand and write the program at rather a large depth.NOC (Number of children) - the number of descendants (direct). The more children, the higher dataabstractness.CBO (Coupling between object classes) - coupling between classes. It shows the number of classes withwhich the original class is connected. All the statements given above for module cohesion are true forthis metric, that is, at high CBO data abstractness decreases and it is more difficult to use the class again.RFC (Response for a class) - RFC=|RS|, where RS is a response set of the class, i.e. a set of methodswhich can be potentially called by a class method in response to data received by the class object. I.e.RS=(({M}({Ri}), i=1...n , where M is all the possible class methods, Ri is all the possible methods which canbe called by i class. Then RFC is potency of this set. The higher RFC, the more complicated testing anddebugging.LCOM (Lack of cohesion in Methods) - lack of methods cohesion. To define this parameter lets considerC class with methods M1, M2, ... ,Mn, then {I1},{I2},...,{In} are sets of variables used in these methods.Now lets define P - it is a set of pairs of methods which have no shared variable. Then LCOM=|P|-|Q|.Lack of cohesion can signal that the class can be divided into several other classes or subclasses, so it isbetter to increase cohesion in order to increase encapsulation of data and reduce complexity of classesand methods.6. Safety metricsThe next type of metrics is metrics close to quantitative ones but based on the number of errors anddefects in a program. There is no sense in examining peculiarities of each of these metrics, it is enoughjust to enumerate them: the number of structure alterations, made since the moment of the previoustest; the number of errors detected during code review; the number of errors detected during programtesting and the number of necessary structure alterations needed for correct operation of the program.For most projects, these indices are considered at one thousand code lines, i.e. the average number ofdefects for a thousand code lines.7. Hybrid metricsIn conclusion we should mention also one more class of metrics called hybrid. The metrics of this classare based on simpler metrics and are their weighted total. The first representative of this class is Cocolsmetric. It is defined in the following way:H_M = (M + R1 * M(M1) + ... + Rn * M(Mn)/(1 + R1 + ... + Rn)where M is the base metrics, Mi is other metrics we are interested in, Ri is a correctly selected ratios andM(Mi) is functions.Functions M(Mi) and ratios Ri are calculated with the help of regressive analysis and task analysis for aparticular program.As the result of investigation, the author of the metrics singled out three models for measures:McCabes, Holsteads and SLOC, where Holsteads measure is used as the base metrics. These modelswere called "the best", "random" and "linear".
  • Zolnovskiy, Simmons and Tayers metrics is also a weighted total of different indices. There are twovariants of this metrics:(structure, interaction, size, data) SUM(a, b, c, d).(interface complexity, computational complexity, input/output complexity, readability) SUM(x, y, z, p).The metrics used are selected in each case depending on the task, and ratios - depending on the role themetrics plays in making a decision in this case.ConclusionTo sum it up, I would like to note that there is no universal metric. Any controllable metriccharacteristics of a program must be controlled depending either on each other, or on a particular task.Besides, you can use hybrid metrics but they also depend on simpler metrics and cannot be universal aswell. Strictly speaking, any metric is only an index which depends greatly on the language and style ofprogramming, thats why you should not absolutize any metric and make your decisions taking intoaccount only this metric.References 1. "Program Verification Systems" Blog: Our first practical research in the sphere of metrics calculation. http://www.viva64.com/blog/en/2009/06/09/111/ 2. A. Novichkov, "Code Metrics and their practical implementation in IBM Rational ClearCase" (RU). http://www.viva64.com/go.php?url=241 3. The Notion of a Metric. Areas of Metrics Use. Metric Scales. Complicity Metrics. Stylistics Metrics. http://www.viva64.com/go.php?url=243 4. T.J. McCabe, "A complexity measure," IEEE Transactions on Software Engineering, vol. SE-2, no. 4, pp. 308-320, December, 1976. 5. D.V.Bogdanov, "Software Life Cycle Standardization", Saint Petersburg, 2000, 210 pages 6. G.N.Kalanov, "Consulting during Enterprises Automation: academic and research edition. "Russia Informational Support on the tThreshold of the XXI century" Series. - Moscow, SINTEG, 1997. - 320 pages. 7. S.K.Chernonozhkin, "Methods and Tools of the Quality Software Development Metrical Support", authors abstract, Novosibirsk, 1998 8. Curtis R. Cook, "Information Theory Metric for Assembly Language" 9. V.Yu.Romanov, "Software Static Analysis". http://www.viva64.com/go.php?url=242 10. Shyam R. Chidamber, Chris F. Kemerer, "A Metrics Suite for Object Oriented Design", 1994