China
Africa
Explore chapters and articles related to this topic
Computational Characteristics of High Performance Embedded Algorithms and Applications
Published in David R. Martinez, Robert A. Bond, Vai M. Michael, High Performance Embedded Computing Handbook, 2018
Arakawa Masahiro, A. Bond Robert
Another way to measure code complexity is to look at the internal structure of the code. For example, cyclomatic complexity measures the number of linearly independent paths through a program (McCabe 1976). Modules with high cyclomatic complexity are difficult to code and maintain. Function points are another way to characterize complexity (Matson, Barrett, and Mellichamp 1994). Whether based on cyclomatic complexity, lines of code, or function points, back-end processing programs tend to be larger, with more internal complexity, than front-end codes. Trackers, graphical user interfaces, decision support systems, schedulers, real-time control programs, and other back-end codes are considerably more complex than beamformers, filters, detectors, and other front-end computations. The amount of effort spent optimizing each line of code in a back-end algorithm may be less than what is needed in the front-end, but the size of the back-end program and its code complexity make up for this. Thus, it cannot be said that one domain is easier to handle than the other; they are just different.
M
Published in Phillip A. Laplante, Dictionary of Computer Science, Engineering, and Technology, 2017
In theory, the higher the cyclomatic complexity, the lower the program reliability and program effort. For example, a piece of spaghetti code would tend to yield a very high cyclomatic complexity. However, a meaningful range can be developed based on historical data for a given application area.
Technical debt as an indicator of software security risk: a machine learning approach for software development enterprises
Published in Enterprise Information Systems, 2022
Miltiadis Siavvas, Dimitrios Tsoukalas, Marija Jankovic, Dionysios Kehagias, Dimitrios Tzovaras
The majority of TD indicators proposed in the literature discover TD items that are linked with software aspects (Tsoukalas et al. 2018; Li, Avgeriou, and Liang 2015; Alves et al. 2016), which enables the evaluation of different software artefacts’ characteristics. With respect to object-oriented software, object-oriented structural properties (Chidamber and Kemerer 1994; Li and Henry 1993), such as the widely known complexity, coupling, and cohesion, have been widely utilised for predicting the maintenance effort and, in turn, the maintainability of software (Riaz, Mendes, and Tempero 2009; Van Koten and Gray 2006; Fioravanti and Nesi 2001; Zhou and Leung 2007; Zhou and Xu 2008), a quality attribute that is closely related to TD. For instance, with respect to the property of complexity, various studies have addressed the impact of Cyclomatic Complexity, i.e. the number of linearly independent paths through a program’s source code, as a predictor of the maintainability of a software project (Giger, Pinzger, and Gall 2012; Bruntink and van Deursen 2006; Singh and Saha 2012). In a similar manner, coupling metrics, such as the Coupling Between Objects (CBO) or the Coupling Between Methods (CBM), and cohesion metrics, such as the Lack of Cohesion in Methods (LCOM), have been considered by a multitude of researchers for their ability to measure and predict (Eski and Buzluca 2011; Shatnawi and Wei 2008; Zhou et al. 2012; Zhou and Leung 2007; Van Koten and Gray 2006; Shatnawi and Wei 2008; Elish and Elish 2009). Therefore, since TD is closely related to the maintainability quality attribute, the aforementioned software metrics are usually being treated as indirect TD indicators or a subset of TD indicators (Kosti et al. 2017; Tsoukalas et al. 2020; Alves et al. 2016; Siebra et al. 2014).