Programming complexity - Revision history

1234qwer1234qwer4: fix spacing around math (via WP:JWB)

2024-10-04T14:11:10Z

fix spacing around math (via WP:JWB)

← Previous revision		Revision as of 14:11, 4 October 2024
Line 31:		Line 31:
	** <math>WMC = \sum_{i=1}^nc_i</math>		** <math>WMC = \sum_{i=1}^nc_i</math>
	** n is the number of methods on the class		** n is the number of methods on the class
	** <math>c_i</math>is the complexity of the method		** <math>c_i</math> is the complexity of the method
	* Coupling between object classes ("CBO")		* Coupling between object classes ("CBO")
	** number of other class which is coupled (using or being used)		** number of other class which is coupled (using or being used)

Widefox: /* See also */ already in body per WP:SEEALSO / WP:OVERLINK

2024-03-24T19:59:10Z

See also: already in body per WP:SEEALSO / WP:OVERLINK

← Previous revision		Revision as of 19:59, 24 March 2024
Line 54:		Line 54:
	*[[Programming paradigm]]		*[[Programming paradigm]]
	*[[Software crisis]]		*[[Software crisis]]
	*[[Software metric]] - quantitative measure of some property of a program

	==References==		==References==

Widefox: /* top */ f

2024-03-24T19:58:26Z

top: f

← Previous revision		Revision as of 19:58, 24 March 2024
Line 1:		Line 1:
	{{Distinguish\|Computational complexity theory}}'''Programming complexity''' (or '''software complexity''') is a term that includes software properties that affect internal interactions. Several commentators distinguish between the terms "complex" and "complicated". Complicated implies being difficult to understand, but ultimately knowable. Complex, by contrast, describes the interactions between entities. As the number of entities increases, the number of interactions between them increases exponentially, making it impossible to know and understand them all. Similarly, higher levels of complexity in software increase the risk of unintentionally interfering with interactions, thus increasing the risk of introducing defects when changing the software. In more extreme cases, it can make modifying the software virtually impossible.		{{Distinguish\|Computational complexity theory}}'''Programming complexity''' (or '''software complexity''') is a term that includes software properties that affect internal interactions. Several commentators distinguish between the terms "complex" and "complicated". Complicated implies being difficult to understand, but ultimately knowable. Complex, by contrast, describes the interactions between entities. As the number of entities increases, the number of interactions between them increases exponentially, making it impossible to know and understand them all. Similarly, higher levels of complexity in software increase the risk of unintentionally interfering with interactions, thus increasing the risk of introducing defects when changing the software. In more extreme cases, it can make modifying the software virtually impossible.

	The idea of linking software complexity to software maintainability has been explored extensively by [[Meir M. Lehman\|Professor Manny Lehman]], who developed his [[Lehman's laws of software evolution\|Laws of Software Evolution]]. He and his co-author [[Les Belady]] explored numerous [[~~Software~~ metrics~~\|Software Metrics~~]] that could be used to measure the state of software, eventually concluding that the only practical solution is to use deterministic complexity models.<ref>MM Lehmam LA Belady; Program Evolution - Processes of Software Change 1985</ref>		The idea of linking software complexity to software maintainability has been explored extensively by [[Meir M. Lehman\|Professor Manny Lehman]], who developed his [[Lehman's laws of software evolution\|Laws of Software Evolution]]. He and his co-author [[Les Belady]] explored numerous [[software metrics]] that could be used to measure the state of software, eventually concluding that the only practical solution is to use deterministic complexity models.<ref>MM Lehmam LA Belady; Program Evolution - Processes of Software Change 1985</ref>

	==Types==		==Types==

Widefox: /* See also */ f

2024-03-24T19:54:47Z

Pmffl: Types is the proper first section

2024-03-13T20:09:12Z

Types is the proper first section

← Previous revision		Revision as of 20:09, 13 March 2024
Line 2:		Line 2:

	The idea of linking software complexity to software maintainability has been explored extensively by [[Meir M. Lehman\|Professor Manny Lehman]], who developed his [[Lehman's laws of software evolution\|Laws of Software Evolution]]. He and his co-author [[Les Belady]] explored numerous [[Software metrics\|Software Metrics]] that could be used to measure the state of software, eventually concluding that the only practical solution is to use deterministic complexity models.<ref>MM Lehmam LA Belady; Program Evolution - Processes of Software Change 1985</ref>		The idea of linking software complexity to software maintainability has been explored extensively by [[Meir M. Lehman\|Professor Manny Lehman]], who developed his [[Lehman's laws of software evolution\|Laws of Software Evolution]]. He and his co-author [[Les Belady]] explored numerous [[Software metrics\|Software Metrics]] that could be used to measure the state of software, eventually concluding that the only practical solution is to use deterministic complexity models.<ref>MM Lehmam LA Belady; Program Evolution - Processes of Software Change 1985</ref>

		⚫	==Types==
		⚫	The complexity of an existing program determines the complexity of changing the program. Problem complexity can be divided into two categories:<ref>[https://academia.edu.documents.s3.amazonaws.com/1811257/SHSM2011.pdf In software engineering, a problem can be divided into its accidental and essential complexity [1<nowiki>]</nowiki>.]</ref>
		⚫	#'''Accidental complexity''' relates to difficulties a programmer faces due to the software engineering tools. Selecting a better tool set or a higher-level programming language may reduce it. Accidental complexity often results from not using the domain to frame the form of the solution.{{Citation needed\|date=September 2015}} [[Domain-driven design]] can help minimize accidental complexity.
		⚫	#'''Essential complexity''' is caused by the characteristics of the problem to be solved and cannot be reduced.

	==Measures==		==Measures==
Line 19:		Line 24:

	[[Law of conservation of complexity\|Tesler's Law]] is an [[adage]] in [[human–computer interaction]] stating that every [[Application software\|application]] has an inherent amount of complexity that cannot be removed or hidden.		[[Law of conservation of complexity\|Tesler's Law]] is an [[adage]] in [[human–computer interaction]] stating that every [[Application software\|application]] has an inherent amount of complexity that cannot be removed or hidden.

⚫	==Types==
⚫	The complexity of an existing program determines the complexity of changing the program. Problem complexity can be divided into two categories:<ref>[https://academia.edu.documents.s3.amazonaws.com/1811257/SHSM2011.pdf In software engineering, a problem can be divided into its accidental and essential complexity [1<nowiki>]</nowiki>.]</ref>
⚫	#'''Accidental complexity''' relates to difficulties a programmer faces due to the software engineering tools. Selecting a better tool set or a higher-level programming language may reduce it. Accidental complexity often results from not using the domain to frame the form of the solution.{{Citation needed\|date=September 2015}} [[Domain-driven design]] can help minimize accidental complexity.
⚫	#'''Essential complexity''' is caused by the characteristics of the problem to be solved and cannot be reduced.

	==Chidamber and Kemerer Metrics==		==Chidamber and Kemerer Metrics==

Thashley: Streamlined text and corrected grammar and punctuation

2023-10-10T14:53:22Z

Streamlined text and corrected grammar and punctuation

← Previous revision		Revision as of 14:53, 10 October 2023
Line 1:		Line 1:
	{{Distinguish\|Computational complexity theory}}'''Programming complexity''' (or '''software complexity''') is a term that includes ~~many~~ properties ~~of a piece of software, all of which~~ affect internal interactions. ~~According to several~~ commentators, ~~there is a distinction~~ between the terms complex and complicated. Complicated implies being difficult to understand but ~~with time and effort,~~ ultimately knowable. Complex, ~~on the other~~ ~~hand~~, describes the interactions between ~~a number of~~ entities. As the number of entities increases, the number of interactions between them ~~would increase~~ exponentially, ~~and~~ it ~~would get to a point where it would be~~ impossible to know and understand all ~~of them~~. Similarly, higher levels of complexity in software increase the risk of unintentionally interfering with interactions ~~and~~ ~~so increases~~ the ~~chance~~ of introducing defects when ~~making~~ ~~changes~~. In more extreme cases, it can make modifying the software virtually impossible. The idea of linking software complexity to ~~the~~ maintainability ~~of the software~~ has been explored extensively by [[Meir M. Lehman\|Professor Manny Lehman]], who developed his [[Lehman's laws of software evolution\|Laws of Software Evolution]] ~~from his research~~. He and his co-author [[Les Belady]] explored numerous ~~possible~~ [[Software metrics\|Software Metrics]] ~~in their oft-cited book,<ref>MM Lehmam LA Belady; Program Evolution - Processes of Software Change 1985</ref>~~ that could be used to measure the state of ~~the~~ software, eventually ~~reaching the conclusion~~ that the only practical solution ~~would be~~ to use ~~one that uses~~ deterministic complexity models.		{{Distinguish\|Computational complexity theory}}'''Programming complexity''' (or '''software complexity''') is a term that includes software properties that affect internal interactions. Several commentators distinguish between the terms "complex" and "complicated". Complicated implies being difficult to understand, but ultimately knowable. Complex, by contrast, describes the interactions between entities. As the number of entities increases, the number of interactions between them increases exponentially, making it impossible to know and understand them all. Similarly, higher levels of complexity in software increase the risk of unintentionally interfering with interactions, thus increasing the risk of introducing defects when changing the software. In more extreme cases, it can make modifying the software virtually impossible.

			The idea of linking software complexity to software maintainability has been explored extensively by [[Meir M. Lehman\|Professor Manny Lehman]], who developed his [[Lehman's laws of software evolution\|Laws of Software Evolution]]. He and his co-author [[Les Belady]] explored numerous [[Software metrics\|Software Metrics]] that could be used to measure the state of software, eventually concluding that the only practical solution is to use deterministic complexity models.<ref>MM Lehmam LA Belady; Program Evolution - Processes of Software Change 1985</ref>

	==Measures==		==Measures==
	~~Many~~ 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		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
	* [[cyclomatic complexity\|McCabe's cyclomatic complexity metric]]		* [[cyclomatic complexity\|McCabe's cyclomatic complexity metric]]
	* [[Halstead complexity measures\|~~Halsteads~~ software science metrics]]		* [[Halstead complexity measures\|Halstead's software science metrics]]
	* Henry and Kafura introduced Software Structure Metrics Based on Information Flow in 1981<ref>Henry, S.; Kafura, D. IEEE Transactions on Software Engineering Volume SE-7, Issue 5, Sept. 1981 Page(s): 510 - 518</ref> 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)²).		* Henry and Kafura introduced "Software Structure Metrics Based on Information Flow" in 1981,<ref>Henry, S.; Kafura, D. IEEE Transactions on Software Engineering Volume SE-7, Issue 5, Sept. 1981 Page(s): 510 - 518</ref> 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)²).
	* A Metrics Suite for Object-Oriented Design<ref name=":0">Chidamber, S.R.; Kemerer, C.F. IEEE Transactions on Software Engineering Volume 20, Issue 6, Jun 1994 Page(s):476 - 493</ref> ~~was introduced by Chidamber and Kemerer in 1994~~ focusing~~, as the title suggests,~~ on metrics ~~specifically~~ for object-oriented code. They introduce six OO complexity metrics; 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		* Chidamber and Kemerer introduced "A Metrics Suite for Object-Oriented Design" in 1994,<ref name=":0">Chidamber, S.R.; Kemerer, C.F. IEEE Transactions on Software Engineering Volume 20, Issue 6, Jun 1994 Page(s):476 - 493</ref> 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.

	~~There are several~~ other metrics ~~that~~ can be used to measure programming complexity:		Several other metrics can be used to measure programming complexity:
	* Branching complexity (Sneed Metric)		* Branching complexity (Sneed Metric)
	* Data access complexity (Card Metric)		* Data access complexity (Card Metric)
Line 19:		Line 21:

	==Types==		==Types==
	~~Associated with, and dependent on the~~ complexity of an existing program, is the complexity ~~associated with~~ changing the program. ~~The~~ complexity ~~of a problem~~ can be divided into two ~~parts~~:<ref>[https://academia.edu.documents.s3.amazonaws.com/1811257/SHSM2011.pdf In software engineering, a problem can be divided into its accidental and essential complexity [1<nowiki>]</nowiki>.]</ref>		The complexity of an existing program determines the complexity of changing the program. Problem complexity can be divided into two categories:<ref>[https://academia.edu.documents.s3.amazonaws.com/1811257/SHSM2011.pdf In software engineering, a problem can be divided into its accidental and essential complexity [1<nowiki>]</nowiki>.]</ref>
	#Accidental complexity: ~~Relates~~ to difficulties a programmer faces due to the ~~chosen~~ software engineering tools. A better ~~fitting~~ set ~~of tools~~ or a ~~more high~~-level programming language may reduce it. Accidental complexity is often ~~also~~ a ~~consequence of the lack of~~ using the domain to frame the form of the solution ~~i.e. the code~~.{{Citation needed\|date=September 2015}} ~~One~~ ~~practice that~~ can help ~~in avoiding~~ accidental complexity ~~is [[domain-driven design]]~~.		#'''Accidental complexity''' relates to difficulties a programmer faces due to the software engineering tools. Selecting a better tool set or a higher-level programming language may reduce it. Accidental complexity often results from not using the domain to frame the form of the solution.{{Citation needed\|date=September 2015}} [[Domain-driven design]] can help minimize accidental complexity.
	#Essential complexity: Is caused by the characteristics of the problem to be solved and cannot be reduced.		#'''Essential complexity''' is caused by the characteristics of the problem to be solved and cannot be reduced.

	==Chidamber and Kemerer Metrics==		==Chidamber and Kemerer Metrics==
	{{Prose\|date=August 2017}}		{{Prose\|date=August 2017}}
	Chidamber and Kemerer<ref name=":0" /> proposed a set of programing complexity metrics, widely used in ~~many~~ measurements and academic articles. ~~They~~ ~~are~~ ~~WMC~~, ~~CBO~~, ~~RFC~~, ~~NOC~~, ~~DIT~~, and ~~LCOM~~, described below:		Chidamber and Kemerer<ref name=":0" /> proposed a set of programing 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:
	* ~~WMC - weighted~~ methods per class		* Weighted methods per class ("WMC")
	** <math>WMC = \sum_{i=1}^nc_i</math>		** <math>WMC = \sum_{i=1}^nc_i</math>
	** n is the number of methods on the class		** n is the number of methods on the class
	** <math>c_i</math>is the complexity of the method		** <math>c_i</math>is the complexity of the method
	* ~~CBO - coupling~~ between object classes		* Coupling between object classes ("CBO")
	** number of other class which is coupled (using or being used)		** number of other class which is coupled (using or being used)
	* ~~RFC - response~~ for a class		* Response for a class ("RFC")
	** <math>RFC = \|RS\|</math> where		** <math>RFC = \|RS\|</math> where
	** <math>RS = \{M\}\cup_{all\ i} \{R_i\}</math>		** <math>RS = \{M\}\cup_{all\ i} \{R_i\}</math>
	** <math>R_i</math> is set of methods called by method i		** <math>R_i</math> is set of methods called by method i
	** <math>M</math> is the set of methods in the class		** <math>M</math> is the set of methods in the class
	* ~~NOC - number~~ of children		* Number of children ("NOC")
	** sum of all classes that inherit this class or a descendant of it		** sum of all classes that inherit this class or a descendant of it
	* ~~DIT - depth~~ of inheritance tree		* Depth of inheritance tree ("DIT")
	** maximum depth of the inheritance tree for this class		** maximum depth of the inheritance tree for this class
	* ~~LCOM- lack~~ of cohesion of methods		* Lack of cohesion of methods ("LCOM")
	** Measures the intersection of the attributes used in common by the class methods		** Measures the intersection of the attributes used in common by the class methods
	** <math>LCOM = \begin{cases} \|P\| - \|Q\|, & \text{if } \|P\| > \|Q\|		** <math>LCOM = \begin{cases} \|P\| - \|Q\|, & \text{if } \|P\| > \|Q\|

204.48.77.247: Fixed typo

2022-09-13T04:45:14Z

Fixed typo

← Previous revision		Revision as of 04:45, 13 September 2022
Line 1:		Line 1:
	{{Distinguish\|Computational complexity theory}}'''Programming complexity''' (or '''software complexity''') is a term that includes many properties of a piece of software, all of which affect internal interactions. According to several commentators, there is a distinction between the terms complex and complicated. Complicated implies being difficult to understand but with time and effort, ultimately knowable. Complex, on the other hand, describes the interactions between a number of entities. As the number of entities increases, the number of interactions between them would increase exponentially, and it would get to a point where it would be impossible to know and understand all of them. Similarly, higher levels of complexity in software increase the risk of unintentionally interfering with interactions and so increases the chance of introducing defects when making changes. In more extreme cases, it can make modifying the software virtually impossible. The idea of linking software complexity to the maintainability of the software has been explored extensively by [[Meir M. Lehman\|Professor Manny Lehman]], who developed his [[Lehman's laws of software evolution\|Laws of Software Evolution]] from his research. He and his co-~~Author~~ [[Les Belady]] explored numerous possible [[Software metrics\|Software Metrics]] in their oft-cited book,<ref>MM Lehmam LA Belady; Program Evolution - Processes of Software Change 1985</ref> that could be used to measure the state of the software, eventually reaching the conclusion that the only practical solution would be to use one that uses deterministic complexity models.		{{Distinguish\|Computational complexity theory}}'''Programming complexity''' (or '''software complexity''') is a term that includes many properties of a piece of software, all of which affect internal interactions. According to several commentators, there is a distinction between the terms complex and complicated. Complicated implies being difficult to understand but with time and effort, ultimately knowable. Complex, on the other hand, describes the interactions between a number of entities. As the number of entities increases, the number of interactions between them would increase exponentially, and it would get to a point where it would be impossible to know and understand all of them. Similarly, higher levels of complexity in software increase the risk of unintentionally interfering with interactions and so increases the chance of introducing defects when making changes. In more extreme cases, it can make modifying the software virtually impossible. The idea of linking software complexity to the maintainability of the software has been explored extensively by [[Meir M. Lehman\|Professor Manny Lehman]], who developed his [[Lehman's laws of software evolution\|Laws of Software Evolution]] from his research. He and his co-author [[Les Belady]] explored numerous possible [[Software metrics\|Software Metrics]] in their oft-cited book,<ref>MM Lehmam LA Belady; Program Evolution - Processes of Software Change 1985</ref> that could be used to measure the state of the software, eventually reaching the conclusion that the only practical solution would be to use one that uses deterministic complexity models.

	==Measures==		==Measures==

134.173.192.65: Added a program complexity metric that has shown to have high correlation with symbolic execution runtime, reader-reported subjective complexity, and brain activation in regions associated with semantic processing.

2021-11-04T03:27:35Z

Added a program complexity metric that has shown to have high correlation with symbolic execution runtime, reader-reported subjective complexity, and brain activation in regions associated with semantic processing.

← Previous revision		Revision as of 03:27, 4 November 2021
Line 14:		Line 14:
	* Data flow complexity (Elshof Metric)		* Data flow complexity (Elshof Metric)
	* Decisional complexity (McClure Metric)		* Decisional complexity (McClure Metric)
			*Path Complexity (Bang Metric)

	[[Law of conservation of complexity\|Tesler's Law]] is an [[adage]] in [[human–computer interaction]] stating that every [[Application software\|application]] has an inherent amount of complexity that cannot be removed or hidden.		[[Law of conservation of complexity\|Tesler's Law]] is an [[adage]] in [[human–computer interaction]] stating that every [[Application software\|application]] has an inherent amount of complexity that cannot be removed or hidden.

2600:1700:87F0:1BF0:0:0:0:2A: I think "descended of it" should be "descendant of it".

2020-11-18T19:17:12Z

I think "descended of it" should be "descendant of it".

← Previous revision		Revision as of 19:17, 18 November 2020
Line 37:		Line 37:
	** <math>M</math> is the set of methods in the class		** <math>M</math> is the set of methods in the class
	* NOC - number of children		* NOC - number of children
	** sum of all classes that inherit this class or a ~~descended~~ of it		** sum of all classes that inherit this class or a descendant of it
	* DIT - depth of inheritance tree		* DIT - depth of inheritance tree
	** maximum depth of the inheritance tree for this class		** maximum depth of the inheritance tree for this class

130.209.157.49: clarify CK LCOM metric definition

2020-01-27T11:16:09Z

clarify CK LCOM metric definition

← Previous revision		Revision as of 11:16, 27 January 2020
Line 46:		Line 46:
	** Where <math>P = \{ (I_i,I_j)\|I_i\cap I_j = \emptyset\}</math>		** Where <math>P = \{ (I_i,I_j)\|I_i\cap I_j = \emptyset\}</math>
	** And <math>Q = \{(I_i, I_j)\|I_i \cap I_j \neq \emptyset\}</math>		** And <math>Q = \{(I_i, I_j)\|I_i \cap I_j \neq \emptyset\}</math>
	** With <math>I_i</math> is the set of ~~the~~ attributes (variables) ~~used~~ by the ~~nth~~ method of the class		** With <math>I_i</math> is the set of attributes (instance variables) accessed (read from or written to) by the <math>i</math>-th method of the class

	==See also==		==See also==

← Previous revision		Revision as of 19:54, 24 March 2024
Line 52:		Line 52:

	==See also==		==See also==
			*[[Programming paradigm]]
	*[[Software crisis]] (and subsequent [[programming paradigm]] solutions)
	*[[Software metric]]s - quantitative measure of some property of a program.		*[[Software crisis]]
			*[[Software metric]] - quantitative measure of some property of a program

	==References==		==References==