Pith. sign in

REVIEW 4 major objections 5 minor 91 references

How does Object-Oriented Code Refactoring Influence Software Quality? Research Landscape and Challenges

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This systematic mapping of 142 empirical studies argues that code refactoring improves or degrades every software quality attribute examined except cohesion, complexity, inheritance, fault-proneness, and power consumption, and that…

desk verdict A solid, transparent systematic map of 142 refactoring studies; the map and the mixed-evidence conclusion hold up, but the attribute-level vote-counting labels are counting-dependent and shouldn't be read as robust. read the letter →

arxiv 1908.05399 v1 pith:JOQHRBN2 submitted 2019-08-15 cs.SE

Satnam Kaur , Paramvir Singh This is my paper · ORCID
classification cs.SE
keywords softwarequalityobject-orientedrefactoringactivitymeasuressystematicmappingstudycodesmellsvote-countingimpact
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to settle a long-running dispute: does refactoring object-oriented code actually improve software quality? It maps 142 empirical studies published through December 2017 and combines their results by vote-counting. The central finding is that refactoring does not always help: across all quality attributes combined, every attribute either improved or degraded except cohesion, complexity, inheritance, fault-proneness, and power consumption, which stayed unsettled. The paper also finds a persistent split between settings: studies run in academia report mostly positive effects, while industrial studies mostly report no detectable effect. This matters because practitioners are reluctant to refactor without evidence, and the paper shows the evidence is weaker and more context-dependent than the textbook promise.

What carries the argument

The vote-counting synthesis is the machinery. Each primary study contributes votes for a quality attribute equal to the product of the number of quality measures, refactoring activities, and datasets it used; significant votes outweigh non-significant ones, and a 50% threshold classifies the attribute's net effect as positive, negative, neutral, or inconsistent. It is the device that turns 142 heterogeneous studies into the paper's headline conclusions.

What would settle it

Recompute the vote-counting results for cohesion, complexity, inheritance, fault-proneness, and power consumption using all votes—significant and non-significant—rather than significant-only votes; the paper itself notes that including non-significant votes changes the classification of Extract Class's effect on inheritance from negative to positive. If for any of the five attributes the 50% threshold flips, the claim that these are the only attributes without a directional effect fails. A second check would re-run the tally with each study contributing one vote per attribute instead of a measure-activity-dataset product and see whether the academic-versus-industrial gap survives.

Watch

Extended reading notes

Core claim

The paper claims that when the 142 primary studies are tallied by vote-counting, overall refactoring is beneficial for coupling, size, encapsulation, messaging, polymorphism, composition, and combinations of attributes, and for most external attributes such as understandability, maintainability, and reusability. It is harmful for adaptability, time behaviour, developers' coordination, productivity, and analysability. Cohesion and inheritance remain unchanged, fault-proneness and power consumption show insignificant change, and complexity is inconsistent, so these five attributes are the exceptions to a directional effect. The paper further claims that academic settings yield positive effects more often than industrial settings, and that individual refactoring activities have variable effects: the same activity can improve one quality attribute while degrading another, and can even improve the same attribute in one study and degrade it in another. Refactoring is therefore not a guaranteed quality improvement, and its measured benefits depend on setting, measures, and datasets.

Load-bearing premise

The synthesis stands or falls on the vote-counting rules: that each study's contribution should be weighted by the product of its quality measures, refactoring activities, and datasets, that non-significant findings can be discarded whenever any significant result exists, and that the 50% threshold cleanly separates positive, negative, neutral, and inconsistent effects.

Editorial extensions

If this is right

  • Practitioners should not assume refactoring is uniformly beneficial; the same activity can improve one quality attribute while degrading another, so refactorings should be chosen with a specific target attribute in mind.
  • Academic results may overstate the benefits of refactoring, so industrial validation with commercial datasets and experienced developers is needed before relying on refactoring for quality improvement.
  • The five unsettled attributes—cohesion, complexity, inheritance, fault-proneness, and power consumption—are the places where the evidence is weakest and where new studies would have the most leverage.
  • The near-total absence of statistical significance testing in the primary studies limits what any synthesis can conclude; more studies reporting significance levels would make the field's evidence base firmer.
  • Only a handful of tools predict or assess refactoring impact, and most are outdated or restricted to Java, leaving a clear gap for tool builders.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the vote-counting weighting is sensitive to the measure-activity-dataset product, the five exception attributes may be an artifact of that weighting rather than a stable finding; a sensitivity analysis using unweighted study counts could flip the classification.
  • The academic-versus-industrial gap may partly reflect dataset type rather than setting itself, since academic studies mostly used open-source systems while industrial studies used commercial ones; the paper does not control for this confound.
  • Contradictions on the same dataset, such as opposite defect findings for ArgoUML, suggest that re-running key studies on JHotDraw, GanttProject, and Apache Ant with a shared metric framework could resolve disputes cheaply.
  • A standard unified metric framework, which the paper recommends, would allow direct comparison across studies and might turn the vote-counting synthesis into a quantitative meta-analysis.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. This paper reports a systematic mapping study (SMS) of 142 primary studies, published up to December 2017, on the effect of object-oriented code refactoring activities on software quality. The authors follow Kitchenham and Charters and Petersen et al., document automatic and manual search procedures, report Cohen's kappa agreement across screening stages, apply a ten-question quality assessment, and classify studies along seven facets. They answer five research questions, using vote-counting for RQ5 to synthesize outcomes on internal and external quality attributes, academic versus industrial settings, and overall versus individual refactoring activities. The headline conclusions are that refactoring improves or degrades most quality attributes except cohesion, complexity, inheritance, fault-proneness, and power consumption, and that academic studies report more positive impact than industrial studies.

Significance. If the RQ5 synthesis were robust, this would be the most comprehensive secondary study to date on the impact of refactoring on object-oriented quality, nearly doubling the primary-study pool of the closest prior SLR and adding an academic/industrial comparison plus tool and dataset classifications. The procedural strengths are real: search strings and screening counts are reported, inter-rater agreement is quantified, quality criteria are explicit, and the online appendix provides extraction data. The central limitation is that the headline attribute-level conclusions are driven by a vote-counting procedure whose weighting and significance-exclusion rules are fragile; because the authors themselves document in Section 5.5 an example where the classification flips, the current framing overstates confidence in both the 'except' list and the academic-versus-industrial contrast. The manuscript is a useful contribution, but the synthesis claims need substantial reframing or sensitivity analysis before publication.

major comments (4)
  1. [4.2.5] Section 4.2.5 defines each primary study's vote contribution for a quality attribute as the product of its number of quality measures, refactoring activities, and datasets, so a single study such as [S25] is reported as contributing 648 votes for cohesion. This multiplicative weighting has no empirical justification and makes vote counts a poor summary of evidence: one study can dominate dozens of others in Tables 11 and 12. Because the final classification depends on a 50% threshold of these weighted votes, the paper should report at least one alternative synthesis at the level of primary studies (for example, one vote per study per attribute) and a sensitivity analysis across plausible weighting schemes before presenting attribute-level conclusions.
  2. [4.2.5 / Section 5.5] The vote-counting procedure discards all non-significant votes for any quality attribute that has at least one statistically significant vote, and Table 6 (QA7) shows that only 18.3% of the 142 primary studies report statistical significance. Consequently, the classifications for cohesion, complexity, size, inheritance, and fault-proneness can rest on a small number of significant votes drawn from very few studies, and the 'except' list is exactly the set of attributes closest to the 50% threshold. The authors acknowledge this fragility in Section 5.5, where the Extract Class/cohesion example flips from negative under significant-only voting to positive when non-significant votes are included; this is a load-bearing caveat, not a minor one. The paper should present both significant-only and all-vote results consistently, and should phrase conclusions as provisional or sensitive to synthesis assumptions.
  3. [4.2.5.1 / 4.2.5.2 / 5.5] The academic-versus-industrial comparison rests on 125 academic versus 17 industrial primary studies, and Section 5.5 itself lists dataset type and quality-measure selection as factors confounded with study setting. The abstract's statement that academic studies 'found more positive impact' of refactoring therefore goes beyond what this mapping design can establish. At minimum, the claim should be reported as an observed association with the confounds named in the same sentence; ideally, the authors should re-analyze a matched subset of studies that controls for dataset type and quality measures, or explicitly state why such a control is impossible.
  4. [4.2.5.3 / Figure 22] Figure 22 and the surrounding text classify 71 individual refactoring-activity/quality-attribute pairs, but Section 4.2.5.3 reports that 590 of the 661 total pairs are investigated by only one or two primary studies, and many displayed pairs are based on a single study. Presenting these as the 'impact' of a refactoring activity without showing the number of supporting studies or confidence information is misleading; Figure 22 should indicate the evidence count per pair, and the text should avoid categorical statements such as 'most refactoring activities have either negative or neutral impact' when the underlying evidence is so sparse.
minor comments (5)
  1. [5.5] The numerical example about Extract Class attributes contains a typo: the counts are introduced for cohesion, but the following sentence refers to inheritance; this should be corrected.
  2. [Abstract / Section 4.2.5] The abstract says refactoring caused all quality attributes to improve or degrade except the listed ones, but Figures 20 and 21 include an explicit 'inconsistent' category; the wording should acknowledge that some attributes are classified as inconsistent rather than simply improved or degraded.
  3. [Figure 5f] The caption of Figure 5f labels the facet as 'Focus (RQ6)', but the study defines only RQ1 through RQ5; this should be corrected to RQ5 or renamed consistently.
  4. [Table 12] In the Fault-Proneness row, the negative-vote study list contains a formatting error — '[S14], [[S38], S68]' has an extra opening bracket before [S38].
  5. [Figure 16] Figure 16 is a very dense matrix of unlabeled numbers and is difficult to interpret; a clearer layout with a legend, or a split into smaller figures, would substantially improve readability.

Circularity Check

0 steps flagged · score 0.0 of 10

The paper is a secondary study synthesizing 142 external primary studies; its vote-counting caveats are robustness threats, not circular reductions.

full rationale

No circular derivation is present. The paper's central RQ5 conclusions (which quality attributes improve, degrade, stay unchanged, or show inconsistent effects after refactoring) are obtained by vote-counting the reported results of 142 external primary studies, with the voting rules explicitly adopted from Dallal and Abdin [21], an independent prior systematic review. There is no fitted parameter renamed as a prediction, no equation in which an output is defined in terms of itself, and no normalization that forces a particular attribute-level outcome. The only self-citation is [41] (Singh and Singh, sharing an author with this paper), used for cautions about automatic search in digital libraries; this citation does not influence the vote counts or the substantive claims about refactoring and quality. The authors themselves acknowledge in Section 5.5 that including non-significant votes could change some classifications, giving the Extract Class/cohesion example; that is a methodological limitation of vote-counting, not a circular step. Because the synthesis is self-contained against external primary-study evidence and the load-bearing analysis does not reduce to the authors' own prior claims, the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper introduces no free parameters, new entities, or fitted quantities. Its conclusions rest on three domain assumptions about the completeness of the literature search, the validity of vote-counting as a synthesis method, and the evidentiary weight of non-significant primary studies. These assumptions are standard for systematic reviews but are not independently verified within the paper.

assumptions (3)
  • domain assumption The 142 primary studies selected via the multi-stage screening are representative of the relevant empirical literature on refactoring and software quality.
    The search, selection, and quality assessment procedures in Section 3 are assumed to capture the relevant evidence without systematic bias.
  • domain assumption Vote-counting with a 50% threshold is an appropriate synthesis method for combining results across heterogeneous studies.
    Adopted from Al Dallal and Abdin [21] and explicitly used in Section 4.2.5; the authors note it may be erroneous in Section 5.5.
  • domain assumption Primary studies' reports of quality impact, even when not statistically significant, are treated as valid evidence for classification.
    Only 26 of 142 studies report statistical significance; the rest are classified by change in metrics (Section 3.5.5).

how reviews work

0 comments
Cite this review

Pith. "Pith review of How does Object-Oriented Code Refactoring Influence Software Quality? Research Landscape and Challenges." pith.science (2026). https://pith.science/paper/JOQHRBN2

@misc{pith2026190805399,
  author       = {Pith},
  title        = {Pith review of: How does Object-Oriented Code Refactoring Influence Software Quality? Research Landscape and Challenges},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JOQHRBN2}},
  note         = {Machine review of arXiv:1908.05399}
}
read the original abstract

Context: Software refactoring aims to improve software quality and developer productivity. Numerous empirical studies investigating the impact of refactoring activities on software quality have been conducted over the last two decades. Objective: This study aims to perform a comprehensive systematic mapping study of existing empirical studies on evaluation of the effect of object-oriented code refactoring activities on software quality attributes. Method: We followed a multi-stage scrutinizing process to select 142 primary studies published till December 2017. The selected primary studies were further classified based on several aspects to answer the research questions defined for this work. In addition, we applied vote-counting approach to combine the empirical results and their analysis reported in primary studies. Results: The findings indicate that studies conducted in academic settings found more positive impact of refactoring on software quality than studies performed in industries. In general, refactoring activities caused all quality attributes to improve or degrade except for cohesion, complexity, inheritance, fault-proneness and power consumption attributes. Furthermore, individual refactoring activities have variable effects on most quality attributes explored in primary studies, indicating that refactoring does not always improve all quality attributes. Conclusions: This study points out several open issues which require further investigation, e.g., lack of industrial validation, lesser coverage of refactoring activities, limited tool support, etc.

Figures

Figures reproduced from arXiv: 1908.05399 by the authors.

Figure 1
Figure 1. Flow chart representation of refactoring steps and our study scope [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Overview of mapping study protocol 3.1 Research questions Following the motivations drawn for this study, we defined following five research questions in order to capture various aspects of empirical studies on refactoring activities and software quality: RQ1. Which refactoring activities and underlying code smells were investigated? RQ2. Which software quality measures have been used to study the impact of refactor… view at source ↗
Figure 3
Figure 3. Mapping of research questions to different stages of refactoring impact determination process [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Stages of article selection process In Stage 3, we firstly merged the results of both automatic and manual searches in Excel spreadsheet. Later, we manually eliminated the duplicate papers from this spreadsheet after sorting them alphabetically by article titles. In su…
Figure 5
Figure 5. Figure 5: Study classification scheme facets along with PSs mapping based - a) research contribution method, b) study context: study setting, c) refactoring activities, d) measures used, e) investigation approach, f) focus Research Method (a) Empirical Research Case Study [S1], …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

91 extracted references · 79 canonical work pages

  1. [1]

    Software engineering: Principles and practice,

    H. van Vliet, “Software engineering: Principles and practice,” second edition, John Wiley and Sons, Chichester, 2000

    2000

  2. [2]

    Distribution of cost over the application lifecycle -a multi -case study,

    R. Zarnekow and W. Brenner, “Distribution of cost over the application lifecycle -a multi -case study,” In: Proc. European Conference on Information Systems, 2005, pp.1-13

    2005

  3. [3]

    Which factors affect software projects maintenance c ost more?,

    S. Dehaghani and N. Hajrahimi, “Which factors affect software projects maintenance c ost more?,” Acta Informatica Medica, vol. 21, no. 1, pp. 63–66, 2013

    2013

  4. [4]

    Prioritizing code-smells correction tasks using chemical reaction optimization,

    A. Ouni, M. Kessentini, S. Bechikh, and H. Sahraoui, “Prioritizing code-smells correction tasks using chemical reaction optimization,” Software Quality Journal, vol. 23, no. 2, pp. 323-361, 2015

    2015

  5. [5]

    High dimensional search -based software engineering: finding tradeoffs among 15 objectives for automating software refactoring using NSGA -III,

    M. W. Mkaouer, M. Kessentini, S. Bechikh, K. Deb, and M. Ó Cinnéide , “High dimensional search -based software engineering: finding tradeoffs among 15 objectives for automating software refactoring using NSGA -III,” In: Proc. Annual Conference on Genetic and Evolutionary Computation, 2014, pp. 1263-1270

    2014

  6. [6]

    AntiPatterns: refactoring software, architectures, and projects in crisis,

    W. H. Brown, R. C. Malveau, H. W. McCormick, and T. J. Mowbray, “AntiPatterns: refactoring software, architectures, and projects in crisis,” John Wiley & Sons, Inc.,1998

    1998

  7. [7]

    Do code smells reflect important maintainability aspects?,

    A. Yamashita and L. Moonen, “Do code smells reflect important maintainability aspects?,” In: Proc. International Conference on Software Maintenance, 2012, pp. 306-315. © 2019. This manuscript version is made available under the CC-BY-NC-ND 4.0 License http://creativecommons.org/licenses/by-nc-nd/4.0/

    2012

  8. [8]

    Refactoring: Improving the design of existing code ,

    M. Fowler, “ Refactoring: Improving the design of existing code ,” Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1999

    1999

Show all 91 references
  1. [9]

    Refactoring: A Program restructuring aid in designing object -oriented application frameworks,

    W.F. Opdyke, “Refactoring: A Program restructuring aid in designing object -oriented application frameworks,” Ph.D. thesis, Univ. of Illinois at Urbana-Champaign, 1992

    1992

  2. [10]

    A Case study on the impact of refactoring on quality and productivity in an agile team,

    R. Moser, P. Abrahamsson, W. Pedrycz, A.Sillitti, and G. Succi , “A Case study on the impact of refactoring on quality and productivity in an agile team,” In: Proc. Balancing Agility and Formalism in Software Engineering, 2008, pp. 252- 266

    2008

  3. [11]

    Refactoring- does it improve software quality?,

    K. Stroggylos and D. Spinellis, “Refactoring- does it improve software quality?,” In: Proc. International Workshop on Software Quality, 2007, pp. 10-16

    2007

  4. [12]

    Are refactorings less error -prone than other changes?,

    P. Weißgerber and S. Diehl, “Are refactorings less error -prone than other changes?,” In: Proc. international workshop on Mining software repositories, 2006, pp. 112-118

    2006

  5. [13]

    An empirical investigation into the role of API -level refactorings during Software evolution,

    M. Kim, D. Cai, and S. Kim, “An empirical investigation into the role of API -level refactorings during Software evolution,” In: Proc International Conference on Software Engineering, 2011, pp. 151-160

    2011

  6. [14]

    Identifying refactorings from source- code changes,

    P. Weißgerber and S. Diehl, “Identifying refactorings from source- code changes,” In: Proc. International Conference on Automated Software Engineering, 2006, pp. 231–240

    2006

  7. [15]

    Error detection by refactoring reconstruction,

    C. Gorg and P. Weißgerber, “Error detection by refactoring reconstruction,” In: Proc. International Workshop on Mining Software Repositories, 2005, pp. 1–5

    2005

  8. [16]

    Challenges to and solutions for refactoring adoption: An industrial perspective,

    T. Sharma, G. Suryanarayana, and G. Samarthyam, “Challenges to and solutions for refactoring adoption: An industrial perspective,” IEEE Software, vol. 32, no. 6, pp. 44–51, 2015

    2015

  9. [17]

    Refactoring -a shot in the dark?,

    M. Leppänen, S. Mäkinen, S. Lahtinen, O. Sievi -Korte, A. P . Tuovinen, and T. Männistö, “Refactoring -a shot in the dark?,” IEEE Software, vol. 32, no. 6, pp. 62-70, 2015

    2015

  10. [18]

    A survey of software refactoring,

    T. Mens and T. Tourwé, “A survey of software refactoring,” IEEE Transactions on Software Engineering, vol. 30, no. 2, pp. 126–139, 2004

    2004

  11. [19]

    A literature review on code smells and refactoring,

    R. D. Wangberg, “A literature review on code smells and refactoring,” Master Thesis, Department of Informatics, University of Oslo, 2010

    2010

  12. [20]

    Trends, opportunities and challenges of software refactoring: A systematic literature review,

    M. Abebe and C.-J. Yoo, “Trends, opportunities and challenges of software refactoring: A systematic literature review,” International Journal of Software Engineering & Its Applications, vol. 8, no. 6, pp. 299–318, 2014

    2014

  13. [21]

    Empirical evaluation of the impact of object-oriented code refactoring on quality attributes: A systematic literature review,

    J. Al Dallal and A. Abdin, “Empirical evaluation of the impact of object-oriented code refactoring on quality attributes: A systematic literature review,” IEEE Transactions on Software Engineering, vol. 44, no. 1, pp. 44–69, 2017

    2017

  14. [22]

    Dynamic profiling -based approach to identifying cost-effective refactorings,

    A.-R. Han and D. -H. Bae, “Dynamic profiling -based approach to identifying cost-effective refactorings,” Information and Software Technology, vol. 55, no. 6, pp. 966–985, 2013

    2013

  15. [23]

    UML model refactoring: A systematic literature review,

    M. Misbhauddin and M. Alshayeb, “UML model refactoring: A systematic literature review,” Empirical Software Engineering, vol. 20, no. 1, pp. 206-251, 2015

    2015

  16. [24]

    Code bad smells: A review of Current Knowledge,

    M. Zhang, T. Hall, and N. Baddoo, “Code bad smells: A review of Current Knowledge,” Journal of Software Maintenance and Evolution: Research and Practice, vol. 23, no. 3, pp. 179-202, 2011

    2011

  17. [25]

    Identifying refactoring opportunities in object-oriented code: A systematic literature review,

    J. Al Dallal, “Identifying refactoring opportunities in object-oriented code: A systematic literature review,” Information and Software Technology, vol. 58, pp. 231–249, 2015

    2015

  18. [26]

    Non -source code refactoring: A systematic literature review,

    S.Rochimah, S. Arifiani, and V.F. Insanittaqwa, “Non -source code refactoring: A systematic literature review,” International Journal of Software Engineering and Its Applications, vol.9, no.6, pp. 197–214, 2015

    2015

  19. [27]

    A review of code smell mining techniques,

    G. Rasool and Z. Arshad, “A review of code smell mining techniques,” Journal of Software: Evolution and Process, vol. 27, no. 11, pp. 867–895, 2015

    2015

  20. [28]

    A systematic review on search-based refactoring,

    T. Mariani and S. R. Vergilio, “A systematic review on search-based refactoring,” Information and Software Technology, vol. 83, pp. 14–34, 2017

    2017

  21. [29]

    A survey of search -based refactoring for software maintenance,

    M. Mohan and D. Greer, “A survey of search -based refactoring for software maintenance,” Journal of Software Engineering and Development, vol. 6, no. 1, p. 3, 2018

    2018

  22. [30]

    A systematic literature review on bad smells—5 W’s: which, when, what, who, where,

    E. V. de Paulo Sobrinho, A. De Lucia, and M. de Almeida Maia, “A systematic literature review on bad smells—5 W’s: which, when, what, who, where,” IEEE Transaction on Software Engineering, 2018

    2018

  23. [31]

    Guidelines for performing systematic literature reviews in software engineering ,

    B. Kitch enham and S. Charters , “Guidelines for performing systematic literature reviews in software engineering ,” Version 2.3, EBSE Technical Report, Keele University, UK, 2007

    2007

  24. [32]

    Systematic mapping studies in sof tware engineering,

    K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson, “Systematic mapping studies in sof tware engineering,” In: Proc. International Conference on Evaluation and Assessment in Software Engineering, 2008, vol. 8, pp. 68–77

    2008

  25. [33]

    Systematic review in software engineering,

    J. Biolchini, P. G. Mian, A. C. C. Natali, and G. H. Travassos, “Systematic review in software engineering,” Technical Report ES-679/05, System Engineering and Computer Science Department PESC-COPPE/UFRJ, vol. 679, no. 5, pp. 45, 2005

    2005

  26. [34]

    A quantitative evaluation of maintainability enhancement by refactoring,

    Y. Kataoka, T. Imai, H. Andou, and T. Fukaya, “A quantitative evaluation of maintainability enhancement by refactoring,” In: Proc. International Conference on Software Maintenance, 2002, pp. 576-585

    2002

  27. [35]

    Requirements engineering for safety -critical systems: A systematic literature review,

    L. E. G. Martins and T. Gorschek, “Requirements engineering for safety -critical systems: A systematic literature review,” Information and Software Technology, vol. 75, pp. 71–89, 2016

    2016

  28. [36]

    http://satnamkaur.in/datasetDepositorySatnam.html

  29. [37]

    Identifying relevant studies in software engineering,

    H. Zhang, M. A. Babar, and P. Tell, “Identifying relevant studies in software engineering,” Information and Software Technology, vol. 53, no. 6, pp. 625–637, 2011

    2011

  30. [38]

    Lessons from applying the systematic literature review process within the software engineering domain,

    P. Brereton, B. A. Kitchenham, D. Budgen, M. Turner, and M. Khalil, “Lessons from applying the systematic literature review process within the software engineering domain,” Journal of systems and software, vol. 80, no. 4, pp. 571–583, 2007

    2007

  31. [39]

    Applying systematic reviews to diverse study types: An experience report

    T. Dybå, T. Dingsöyr, and G.K. Hanssen, “Applying systematic reviews to diverse study types: An experience report.” In: Proc. International Symposium on Empirical Software Engineering and Measurement, 2007, pp. 225–234. © 2019. This manuscript version is made available under t...

    2007

  32. [40]

    Performance analysis for object -oriented software: A systematic mapping,

    D. Maplesden, E. Tempero, J. Hosking, and J. C. Gru ndy, “Performance analysis for object -oriented software: A systematic mapping,” IEEE Transactions on Software Engineering, vol. 41, no. 7, pp. 691–710, 2015

    2015

  33. [41]

    Exploring Automatic Search in Digital Libraries: A Caution Guide for Systematic Reviewers,

    P. Singh and K. Singh, “Exploring Automatic Search in Digital Libraries: A Caution Guide for Systematic Reviewers,” In: Proc. International Conference on Evaluation and Assessment in Software Engineering, 2017, pp. 236-241

    2017

  34. [42]

    Evaluation of the impact of code refactoring on embedded software efficiency,

    W. G. da Silva, L. Brisolara, U. B. Corrêa, and L. Carro, “Evaluation of the impact of code refactoring on embedded software efficiency,” In: Proc Workshop de Sistemas Embarcados, 2010, pp. 145–150

    2010

  35. [43]

    Does god class decomposition affect comprehensibility?,

    B. Du Bois, S. Demeyer, J. Verelst, T. Mens, and M. Temmerman, “Does god class decomposition affect comprehensibility?,” In: Proc. IASTED Conference on Software Engineering, 2006, pp. 346–355

    2006

  36. [44]

    A coefficient of agreement for nominal scales,

    J. Cohen, “A coefficient of agreement for nominal scales,” Educational and Psychological Measurement, vol. 20, no. 1, pp. 37–46, 1960

    1960

  37. [45]

    Can metrics help bridging the gap between the improvement of OO design quality and its automation?,

    H. Sahraoui, R. Godin, and T. Miceli, “Can metrics help bridging the gap between the improvement of OO design quality and its automation?,” In: Proc. International Conference on Software Maintenance,2000, pp. 154–162

    2000

  38. [46]

    Measurement of observer agreement for categorical data,

    J.R. Landis and G.G. Koch, “Measurement of observer agreement for categorical data,” Biometrics, vol. 33, no. 1, pp. 159–174, 1977

    1977

  39. [47]

    The impact of static -dynamic coupling on remodularization,

    R. Chern and K. De Volder, “The impact of static -dynamic coupling on remodularization,” In: Proc. ACM Sigplan Notices, vol. 43, no. 10, pp. 261–276, 2008

    2008

  40. [48]

    The impact of accounting for special methods in the measurement of object -oriented class cohesion on refactoring and fault prediction activities,

    J. Al Dallal, “The impact of accounting for special methods in the measurement of object -oriented class cohesion on refactoring and fault prediction activities,” Journal of systems and software, vol. 85, no. 5, pp. 1042–1057, 2012

    2012

  41. [49]

    Identifying strategies for study selection in systematic reviews and maps ,

    K. Petersen and N.B. Ali , “ Identifying strategies for study selection in systematic reviews and maps ,” In: Proc. International Symposium on Empirical Software Engineering and Measurement (ESEM), 2011, pp. 351-354

    2011

  42. [50]

    Quali ty attributes and quality models for ambient assisted living software systems: A systematic mapping,

    L. Garcés, A. Ampatzoglou, P. Avgeriou, and E. Y. Nakagawa, “Quali ty attributes and quality models for ambient assisted living software systems: A systematic mapping,” Information and Software Technology, vol. 82, pp. 121–138, 2017

    2017

  43. [51]

    Software startup engineering: A systematic mapping study,

    V. Berg, J. Birkeland, A. Nguyen -Duc, I. O. Papp as, and L. Jaccheri, “ Software startup engineering: A systematic mapping study,” Journal of systems and software, vol. 144, pp. 255–274, 2018

    2018

  44. [52]

    A systematic mapping study of i nfrastructure as code research,

    A. Rahman, R. Mah davi-Hezaveh, and L. Williams, “ A systematic mapping study of i nfrastructure as code research,” Information and Software Technology, vol. 108, pp. 65–77, 2019

    2019

  45. [53]

    Deriving architectural models from requirements specificatio ns: A systematic mapping study,

    E. Souza, A. Moreira, and M. Goulão, “ Deriving architectural models from requirements specificatio ns: A systematic mapping study,” Information and Software Technology, 2019

    2019

  46. [54]

    Experimental assessment of software metrics using automated refactoring,

    M. Ó Cinnéide, L. Tratt, M. Harman, S. Counsell, and I. H. Moghadam, “Experimental assessment of software metrics using automated refactoring,” In: Proc. International Symposium on Empirical Software Engineering and Management (ESEM), 2012, pp. 49-58

    2012

  47. [55]

    An experimental search-based approach to cohesion metric evaluation,

    M.Ó. Cinnéide, I. Hemati Moghadam, M. Harman, S. Counsell, and L. Tratt, “An experimental search-based approach to cohesion metric evaluation,” Empirical Software Engineering, vol. 22, no. 1, pp. 292-329, 2016

    2016

  48. [56]

    A systematic survey of program comprehension through dynamic analysis,

    B. Cornelissen, A. Zaidman, A. Van Deursen, L. Moonen, and R. Koschke, “A systematic survey of program comprehension through dynamic analysis, ” IEEE Transactions on Software Engineering , vol. 35, no. 5, pp. 684-702, 2009

    2009

  49. [57]

    Empirical evidence on the link between object -oriented measures and external quality attributes: A systematic literature review,

    R. Jabangwe, J. Börstler, D. Šmite, and C. Wohlin, “Empirical evidence on the link between object -oriented measures and external quality attributes: A systematic literature review,” Empirical Software Engineering, vol. 20, no. 3, pp 640- 693, 2015

    2015

  50. [58]

    A systematic review of comparative evidence of aspect -oriented programming,

    M. S. Ali, M. A. Babar, L. Chen, and K. -J. Stol, “A systematic review of comparative evidence of aspect -oriented programming,” Information and Software Technology vol. 52, no. 9, pp. 871–887, 2010

    2010

  51. [59]

    Applying meta-analytical procedures to software engineering experiments,

    J. Miller, “Applying meta-analytical procedures to software engineering experiments,” Journal of Systems and Software, vol. 54, no. 1, pp. 29–39, 2000

    2000

  52. [60]

    Vote -counting for combining quantitative evidence from empirical studies -an example,

    P. Mohagheghi and R. Conradi, “Vote -counting for combining quantitative evidence from empirical studies -an example,” In: Proc. International Symposium on Empirical Software Engineering (ISESE’04), 2004

    2004

  53. [61]

    Combining empirical results in software engineering,

    L. M. Pickard, B. A. Kitchenham, and P. W. Jones, “Combining empirical results in software engineering,” Information and Software Technology, vol. 40, no. 14, pp. 811–821, 1998

    1998

  54. [62]

    The effects of test driven development on internal quality, external quality and productivity: A systematic review,

    W. Bissi, A. G. S. S. Neto, and M. C. F. P. Emer, “The effects of test driven development on internal quality, external quality and productivity: A systematic review,” Information and Software Technology, vol. 74, pp. 45–54, 2016

    2016

  55. [63]

    Software fault prediction metrics: A systematic literature review,

    D. Radjenović, M. Heričko, R. Torkar, and A. Živkovič, “Software fault prediction metrics: A systematic literature review,” Information and Software Technology, vol. 55, no. 8, pp. 1397–1418, 2013

    2013

  56. [64]

    Experiences using systematic review guidelines,

    M. Staples and M. Niazi, “Experiences using systematic review guidelines,” Journal of Systems and Software, vol. 80, no. 9, pp. 1425–1437, 2007

    2007

  57. [65]

    Software metrics a rigorous & practical approach,

    N.E. Fenton and S. Lawrence Pfleeger, “Software metrics a rigorous & practical approach,” second edition, International Thomson Computer Press, London, UK, 1997

    1997

  58. [66]

    A probability -based approach for measuring external attributes of software artifacts,

    S. Morasca, “A probability -based approach for measuring external attributes of software artifacts,” In: Proc. International Symposium on Empirical Software Engineering and Measurement, 2009, pp. 44–55

    2009

  59. [67]

    Template- based reconstruction of complex refactorings,

    K. Prete, N. Rachatasumrit, N. Sudan, and M. Kim, “Template- based reconstruction of complex refactorings,” In: Proc. International Conference on Software Maintenance, 2010, pp. 1-10

    2010

  60. [68]

    Correlation between object - oriented metrics and refactoring,

    D. Boshnakoska and A. Mišev, “Correlation between object - oriented metrics and refactoring,” In: Proc. International Conference on ICT Innovations, Communication in Computer and Information Science, 2011, pp. 226-235

    2011

  61. [69]

    A metrics suite for object oriented design,

    S. R. Chidamber and C. F. Kemerer, “A metrics suite for object oriented design,” IEEE Transactions on softwa re engineering, vol. 20, no. 6, pp. 476–493, 1994

    1994

  62. [70]

    Towards a metrics suite for object oriented design,

    S.R. Chidamber and C.F. Kemerer, “Towards a metrics suite for object oriented design,” In: Proc. International Conference on ObjectOriented Programming: Systems, Languages and Applications, 1991, pp. 197-211. © 2019. This manuscript version is made available under the CC-BY-NC...

    1991

  63. [71]

    Object-oriented metrics that predict maintainability ,

    W. Li and S. Henry, “ Object-oriented metrics that predict maintainability ,” Journal of Systems and Software, vol. 23, no. 2, pp. 111–122, 1993

    1993

  64. [72]

    Object-oriented software metrics: A practical guide,

    M. Lorenz and J. Kidd, “Object-oriented software metrics: A practical guide,” Prentice-Hall, New Jersey, USA, 1994

    1994

  65. [73]

    A unified framework for coupling in object -oriented systems ,

    L.C. Briand, J.W. Daly, and J.K. Wust, “A unified framework for coupling in object -oriented systems ,” IEEE Transactions on Software Engineering, vol. 25, no. 1, pp. 91-121, 1999

    1999

  66. [74]

    Object -oriented software engineering : Measuring and controlling the development process,

    F. B. Abreu and R. Carapuça, “Object -oriented software engineering : Measuring and controlling the development process,” In: Proc. International Conference on Software Quality, 1994, pp. 1-8

    1994

  67. [75]

    A hierarchical model for object -oriented design quality assessment,

    J. Bansiya and C. G. Davis, “A hierarchical model for object -oriented design quality assessment,” IEEE Transactions on Software Engineering, vol. 28, no. 1, pp. 4–17, 2002

    2002

  68. [76]

    https://sites.google.com/a/ic.ufal.br/ refactoringplatform/

  69. [77]

    Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models,

    ISO/IEC-25010, “Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models,” International organization for standardization, 2010

    2010

  70. [78]

    Assessment of Approa ches for the Analysis of Refactoring Activity on Software Repositories An Empirical Study,

    M. Orrú and M. Marchesi , “ Assessment of Approa ches for the Analysis of Refactoring Activity on Software Repositories An Empirical Study,” In: Proc. Scientific Workshop Proceedings of XP2016, 2016, pp. 22

    2016

  71. [79]

    How we refactor, and how we know it,

    E. Murphy-Hill, C. Parnin, and A. Black, “How we refactor, and how we know it,” IEEE Transactions on Software Engineering, vol. 38, no. 1, pp. 5-18, 2012

    2012

  72. [80]

    Straightening spaghetti-code with refactoring?,

    M. Pizka, “Straightening spaghetti-code with refactoring?,” In: Proc. International Conference On Software Engineering Research and Practice, 2004, pp. 846-852

    2004

  73. [81]

    Jdeodorant: Identification and removal of feature envy bad smells,

    M. Fokaefs, N. Tsantalis, and A. Chat zigeorgiou, “Jdeodorant: Identification and removal of feature envy bad smells,” In: Proc. International Conference on Software Maintenance, 2007, pp. 519-520

    2007

  74. [82]

    Extracting refactoring trends from open -source software and a possible solution to the ‘related refactoring’ conundrum,

    D. Advani, Y. Hassoun, and S. Counsell, “Extracting refactoring trends from open -source software and a possible solution to the ‘related refactoring’ conundrum,” In: Proc ACM Symposium on Applied Computing , 2006, pp. 1713 – 1720

    2006

  75. [83]

    Why we refactor? confessions of github contributors,

    D. Silva, N. Tsantalis, and M. T. Valente, “Why we refactor? confessions of github contributors,” In: Proc International Symposium on Foundations of Software Engineering, 2016, pp. 858–870

    2016

  76. [84]

    An empirical study of refactoring challenges and benefits at Microsoft,

    M. Kim, T. Zimmermann, and N. Nagappan, “An empirical study of refactoring challenges and benefits at Microsoft,” IEEE Transactions on Software Engineering, vol. 40, no. 7, pp. 633-649, 2014

    2014

  77. [85]

    Refactoring effect estimation based on complexity metrics,

    Y. Higo, Y. Matsumoto, S. Kusumoto, and K. Inoue, “Refactoring effect estimation based on complexity metrics,” In: Proc. Australian Conference on Software Engineering , 2008, pp. 219–228

    2008

  78. [86]

    On the alignment of source code quality perspectives through experimentation: an industrial case,

    T. V. Ribeiro and G. H. Travassos, “On the alignment of source code quality perspectives through experimentation: an industrial case,” In: Proc International Workshop on Conducting Empirical Studies in Industry, 2015, pp. 26–33

    2015

  79. [87]

    Factors in Software Quality,

    J. A. McCall, P. K. Richards, and G. F. Walters, “Factors in Software Quality,” National Technical Information Service, vol. 1, 2 and 3, 1977

    1977

  80. [88]

    Characteristics of Software Quality,

    B. W. Boehm, J. R. Brown, H. Kaspar, M. Lipow, G. McLeod, and M. Merritt , “Characteristics of Software Quality,” North Holland, 1978

    1978

  81. [89]

    Aggregation of empirical evidence,

    M. Ciolkowski, “Aggregation of empirical evidence,” in Empirical Software Engineering Issues. Critical Assessment and Future Directions, Springer, 2007, pp. 20–20

    2007

  82. [90]

    Experimentation in software engineering,

    C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and A. Wesslén, “Experimentation in software engineering,” first edition, Springer Berlin Heidelberg, 2012

    2012

  83. [91]

    Selecting empirical methods for software engineering research,

    S. Easterbrook, J. Singer, M. -A. Storey, and D. Damian, “Selecting empirical methods for software engineering research,” Guide to advanced empirical software engineering, Springer, 2008, pp. 285–311. APPENDIX PRIMARY STUDIES [S1] B. Alshammari, C. Fidge, and D. Corney, “Secur...

    2008

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.