Programming complexity

Measures

Several measures of software complexity have been proposed. Many of these, although yielding a good representation of complexity, do not lend themselves to easy measurement. Some of the more commonly used metrics are

• McCabe's cyclomatic complexity metric
• Halstead's software science metrics
• Henry and Kafura introduced "Software Structure Metrics Based on Information Flow" in 1981, which measures complexity as a function of "fan-in" and "fan-out". They define fan-in of a procedure as the number of local flows into that procedure plus the number of data structures from which that procedure retrieves information. Fan-out is defined as the number of local flows out of that procedure plus the number of data structures that the procedure updates. Local flows relate to data passed to, and from procedures that call or are called by, the procedure in question. Henry and Kafura's complexity value is defined as "the procedure length multiplied by the square of fan-in multiplied by fan-out" (Length ×(fan-in × fan-out)²).
• Chidamber and Kemerer introduced "A Metrics Suite for Object-Oriented Design" in 1994, focusing on metrics for object-oriented code. They introduce six OO complexity metrics: (1) weighted methods per class; (2) coupling between object classes; (3) response for a class; (4) number of children; (5) depth of inheritance tree; and (6) lack of cohesion of methods.

Several other metrics can be used to measure programming complexity:

• Branching complexity (Sneed Metric)
• Data access complexity (Card Metric)
• Data complexity (Chapin Metric)
• Data flow complexity (Elshof Metric)
• Decisional complexity (McClure Metric)
• Path Complexity (Bang Metric)

Tesler's Law is an adage in human–computer interaction stating that every application has an inherent amount of complexity that cannot be removed or hidden.

Chidamber and Kemerer Metrics

Chidamber and Kemerer proposed a set of programming complexity metrics widely used in measurements and academic articles: weighted methods per class, coupling between object classes, response for a class, number of children, depth of inheritance tree, and lack of cohesion of methods, described below:

• Weighted methods per class ("WMC")
  • ${\displaystyle WMC=\sum _{i=1}^n{c}_i}$
  • n is the number of methods on the class
  • ${\displaystyle c_i}$ is the complexity of the method
• Coupling between object classes ("CBO")
  • number of other class which is coupled (using or being used)
• Response for a class ("RFC")
  • ${\displaystyle RFC=|RS|}$ where
  • ${\displaystyle RS=\{M\}{\cup }_{alli}\{R_i\}}$
  • ${\displaystyle R_i}$ is set of methods called by method i
  • ${\displaystyle M}$ is the set of methods in the class
• Number of children ("NOC")
  • sum of all classes that inherit this class or a descendant of it
• Depth of inheritance tree ("DIT")
  • maximum depth of the inheritance tree for this class
• Lack of cohesion of methods ("LCOM")
  • Measures the intersection of the attributes used in common by the class methods
  • ${\displaystyle LCOM=\{\begin{array}{ll}|P|-|Q|,& \text{if }|P|>|Q|\\ 0,& \text{otherwise }\end{array}}$
  • Where ${\displaystyle P=\{(I_i,I_j)|I_i\cap I_j=\mathrm{\varnothing }\}}$
  • And ${\displaystyle Q=\{(I_i,I_j)|I_i\cap I_j\ne \mathrm{\varnothing }\}}$
  • With ${\displaystyle I_i}$ is the set of attributes (instance variables) accessed (read from or written to) by the ${\displaystyle i}$-th method of the class