A taxonomy of metrics for software fault prediction

Caulo, Maria

doi:10.1145/3338906.3341462

Cited by 3 publications

(4 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This is particularly true for software metrics, which often cannot be compared directly, because due to their different scales and distributions, there does not exist a mathematically sound way to do so (Ulan et al, 2018). While some have attempted to associate blank software metrics with quality (e.g., Basili et al, 1996), most often applications have to resort to using software metrics as, e.g., fault indicators (Aziz et al, 2019;Caulo, 2019), or as indicators of reliability and complexity (Chidamber & Kemerer, 1994). Furthermore, none of the existing approaches that attempted to associate software metrics with quality paid great attention to the fact that software metrics have different distributions and, therefore, different statistical properties across application domains.…”

Section: Statement Of Needmentioning

confidence: 99%

Metrics As Scores: A Tool- and Analysis Suite and Interactive Application for Exploring Context-Dependent Distributions

Hönel,

Ericsson,

Löwe

et al. 2023

JOSS

View full text Add to dashboard Cite

Metrics As Scores can be thought of as an interactive, multiple analysis of variance (abbr. "ANOVA," Chambers et al., 2017). An ANOVA might be used to estimate the goodness-of-fit of a statistical model. Beyond ANOVA, which is used to analyze the differences among hypothesized group means for a single quantity (feature), Metrics As Scores seeks to answer the question of whether a sample of a certain feature is more or less common across groups. This approach to data visualization and -exploration has been used previously (e.g., Jiang et al., 2022). Beyond this, Metrics As Scores can determine what might constitute a good/bad, acceptable/alarming, or common/extreme value, and how distant the sample is from that value, for each group. This is expressed in terms of a percentile (a standardized scale of [0, 1]), which we call score. Considering all available features among the existing groups furthermore allows the user to assess how different the groups are from each other, or whether they are indistinguishable from one another.

show abstract

Section: Statement Of Needmentioning

confidence: 99%

Metrics As Scores: A Tool- and Analysis Suite and Interactive Application for Exploring Context-Dependent Distributions

Hönel,

Ericsson,

Löwe

et al. 2023

JOSS

View full text Add to dashboard Cite

show abstract

“…During the decades of the static analysis of code, many metrics were engineered for measuring such structural properties as code complexity [24] or maintainability [9]. The most exhaustive set of metrics was presented in the work of Caulo et al [7] -the authors collected over 300 different metrics for code evaluation. While some of these metrics are not applicable for Python, there are several works that focused specifically on evaluating Python code.…”

Section: Structural Studies On Codementioning

confidence: 99%

“…Firstly, we analyzed the existing papers about structural metrics in software engineering [15,32], most notably, the work of Caulo et al that presented the list of 300 such metrics [7]. Since most of the structural metrics were originally created for analysing objectoriented programming code, it is an additional challenge to apply these metrics to notebooks, where classes are rarely used [30].…”

Section: Structural Metricsmentioning

confidence: 99%

“…There exist different approaches to studying source code [7]. We chose to separate our analysis into two logical parts: (1) structural analysis -which includes the raw properties of the code, such as complexity metrics, function counts, etc., and (2) stylistic analysis -which is focused on inefficient coding patterns and styling violations.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

A Large-Scale Comparison of Python Code in Jupyter Notebooks and Scripts

Grotov¹,

Титов²,

Sotnikov³

et al. 2022

Preprint

View full text Add to dashboard Cite

In recent years, Jupyter notebooks have grown in popularity in several domains of software engineering, such as data science, machine learning, and computer science education. Their popularity has to do with their rich features for presenting and visualizing data, however, recent studies show that notebooks also share a lot of drawbacks: high number of code clones, low reproducibility, etc.In this work, we carry out a comparison between Python code written in Jupyter Notebooks and in traditional Python scripts. We compare the code from two perspectives: structural and stylistic. In the first part of the analysis, we report the difference in the number of lines, the usage of functions, as well as various complexity metrics. In the second part, we show the difference in the number of stylistic issues and provide an extensive overview of the 15 most frequent stylistic issues in the studied mediums. Overall, we demonstrate that notebooks are characterized by the lower code complexity, however, their code could be perceived as more entangled than in the scripts. As for the style, notebooks tend to have 1.4 times more stylistic issues, but at the same time, some of them are caused by specific coding practices in notebooks and should be considered as false positives. With this research, we want to pave the way to studying specific problems of notebooks that should be addressed by the development of notebook-specific tools, and provide various insights that can be useful in this regard.

show abstract