@article {SAN17,
	title = {Empirical Study on Refactoring Large-scale Industrial Systems and Its Effects on Maintainability},
	journal = {Journal of Systems and Software},
	volume = {129},
	number = {C},
	year = {2017},
	month = {jul},
	pages = {107{\textendash}126},
	abstract = {We examine hundreds of manual refactoring commits from large-scale industrial systems.We study the effects of these commits on source code using a maintainability model.Developers preferred to fix concrete coding issues rather than fix code smells.A single refactoring had only a small impact (sometimes even negative effect).Whole refactoring process has significant beneficial effect on the maintainability. Software evolves continuously, it gets modified, enhanced, and new requirements always arise. If we do not spend time occasionally on improving our source code, its maintainability will inevitably decrease. The literature tells us that we can improve the maintainability of a software system by regularly refactoring it. But does refactoring really increase software maintainability? Can it happen that refactoring decreases the maintainability? Empirical studies show contradicting answers to these questions and there have been only a few studies which were performed in a large-scale, industrial context. In our paper, we assess these questions in an in vivo context, where we analyzed the source code and measured the maintainability of 6 large-scale, proprietary software systems in their manual refactoring phase. We analyzed 2.5 million lines of code and studied the effects on maintainability of 315 refactoring commits which fixed 1273 coding issues. We found that single refactorings only make a very little difference (sometimes even decrease maintainability), but a whole refactoring period, in general, can significantly increase maintainability, which can result not only in the local, but also in the global improvement of the code.},
	keywords = {Antipatterns, coding issues, ISO/IEC 25010, maintainability, refactoring, select:quality, software quality},
	issn = {0164-1212},
	doi = {10.1016/j.jss.2016.08.071},
	url = {http://www.sciencedirect.com/science/article/pii/S0164121216301558?via\%3Dihub},
	author = {Sz{\H o}ke, G{\'a}bor and Antal, G{\'a}bor and Csaba Nagy and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
@conference {TVF15,
	title = {Comparison of Static Analysis Tools for Quality Measurement of {RPG} Programs},
	booktitle = {Proceedings of the 15th International Conference on Computational Science and Its Applications (ICCSA 2015)},
	series = {Lecture Notes in Computer Science (LNCS)},
	volume = {9159},
	year = {2015},
	month = {jun},
	pages = {177{\textendash}192},
	publisher = {Springer-Verlag},
	organization = {Springer-Verlag},
	address = {Banff, Alberta, Canada},
	abstract = {The RPG programming language is a popular language employed widely in IBM i mainframes nowadays. Legacy mainframe systems that evolved and survived the past decades usually data intensive and even business critical applications. Recent, state of the art quality assurance tools are mostly focused on popular languages like Java, C++ or Python. In this work we compare two source code based quality management tools for the RPG language. The study is focused on the data obtained using static analysis, which is then aggregated to higher level quality attributes. SourceMeter is a command line tool-chain capable to measure various source attributes like metrics and coding rule violations. SonarQube is a quality management platform with RPG language support. To facilitate the objective comparison, we used the SourceMeter for RPG plugin for SonarQube, which seamlessly integrates into the framework extending its capabilities. The evaluation is built on analysis success and depth, source code metrics, coding rules and code duplications. We found that SourceMeter is more advanced in analysis depth, product metrics and finding duplications, while their performance of coding rules and analysis success is rather balanced. Since both tools were presented recently on the market of quality assurance tools, we expect additional releases in the future with more mature analyzers.},
	keywords = {Coding rules, IBM RPG, metrics, software quality, SonarQube, SourceMeter, Static Analysis},
	doi = {10.1007/978-3-319-21413-9_13},
	url = {https://link.springer.com/chapter/10.1007\%2F978-3-319-21413-9_13},
	author = {T{\'o}th, Zolt{\'a}n and L{\'a}szl{\'o} Vid{\'a}cs and Rudolf Ferenc}
}
@conference {SAN14,
	title = {Bulk Fixing Coding Issues and Its Effects on Software Quality: Is It Worth Refactoring?},
	booktitle = {Proceedings of the 14th IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM 2014)},
	year = {2014},
	month = {sep},
	pages = {95{\textendash}104},
	publisher = {IEEE Computer Society},
	organization = {IEEE Computer Society},
	address = {Victoria, British Columbia, Canada},
	abstract = {The quality of a software system is mostly defined by its source code. Software evolves continuously, it gets modified, enhanced, and new requirements always arise. If we do not spend time periodically on improving our source code, it becomes messy and its quality will decrease inevitably. Literature tells us that we can improve the quality of our software product by regularly refactoring it. But does refactoring really increase software quality? Can it happen that a refactoring decreases the quality? Is it possible to recognize the change in quality caused by a single refactoring operation? In our paper, we seek answers to these questions in a case study of refactoring large-scale proprietary software systems. We analyzed the source code of 5 systems, and measured the quality of several revisions for a period of time. We analyzed 2 million lines of code and identified nearly 200 refactoring commits which fixed over 500 coding issues. We found that one single refactoring only makes a small change (sometimes even decreases quality), but when we do them in blocks, we can significantly increase quality, which can result not only in the local, but also in the global improvement of the code.},
	keywords = {Antipatterns, coding issues, ISO/IEC 25010, maintainability, software quality},
	doi = {10.1109/SCAM.2014.18},
	url = {http://ieeexplore.ieee.org/document/6975643/},
	author = {Sz{\H o}ke, G{\'a}bor and Antal, G{\'a}bor and Csaba Nagy and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
@conference {SNF14,
	title = {A Case Study of Refactoring Large-Scale Industrial Systems to Efficiently Improve Source Code Quality},
	booktitle = {Proceedings of the 14th International Conference on Computational Science and Its Applications (ICCSA 2014)},
	series = {Lecture Notes in Computer Science (LNCS)},
	volume = {8583},
	year = {2014},
	month = {jun},
	pages = {524{\textendash}540},
	publisher = {Springer-Verlag},
	organization = {Springer-Verlag},
	address = {Guimar{\~a}es, Portugal},
	abstract = {Refactoring source code has many benefits (e.g. improving maintainability, robustness and source code quality), but it takes time away from other implementation tasks, resulting in developers neglecting refactoring steps during the development process. But what happens when they know that the quality of their source code needs to be improved and they can get the extra time and money to refactor the code? What will they do? What will they consider the most important for improving source code quality? What sort of issues will they address first or last and how will they solve them? In our paper, we look for answers to these questions in a case study of refactoring large-scale industrial systems where developers participated in a project to improve the quality of their software systems. We collected empirical data of over a thousand refactoring patches for 5 systems with over 5 million lines of code in total, and we found that developers really optimized the refactoring process to significantly improve the quality of these systems.},
	keywords = {refactoring, Software engineering, software quality},
	doi = {10.1007/978-3-319-09156-3_37},
	url = {https://link.springer.com/chapter/10.1007\%2F978-3-319-09156-3_37},
	author = {Sz{\H o}ke, G{\'a}bor and Csaba Nagy and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
@conference {FLS14,
	title = {{SourceMeter} {SonarQube} plug-in},
	booktitle = {Proceedings of the 14th IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM 2014)},
	year = {2014},
	month = {sep},
	pages = {77{\textendash}82},
	publisher = {IEEE Computer Society},
	organization = {IEEE Computer Society},
	address = {Victoria, British Columbia, Canada},
	abstract = {The SourceMeter Sonar Qube plug-in is an extension of Sonar Qube, an open-source platform for managing code quality made by Sonar Source S.A, Switzerland. The plug-in extends the built-in Java code analysis engine of Sonar Qube with Front End ART{\textquoteright}s high-end Java code analysis engine. Most of Sonar Qubes original analysis results are replaced (including the detected source code duplications), while the range of available analyses is extended with a number of additional metrics and issue detectors. Additionally, the plug-in offers new GUI features on the Sonar Qube dashboard and drilldown views, making the Sonar Qube user experience more comfortable and the work with the tool more productive.},
	keywords = {clone detection, coding issues, metrics, plug-in, software quality, Sonar Qube, Source Meter},
	doi = {10.1109/SCAM.2014.31},
	url = {http://ieeexplore.ieee.org/document/6975640/},
	author = {Rudolf Ferenc and Lang{\'o}, L{\'a}szl{\'o} and Istv{\'a}n Siket and Tibor Gyim{\'o}thy and Tibor Bakota}
}
@conference {6080791,
	title = {A probabilistic software quality model},
	booktitle = {Software Maintenance (ICSM), 2011 27th IEEE International Conference on},
	year = {2011},
	month = {sept.},
	pages = {243 -252},
	keywords = {cost estimation, costing, development cost, IEC standards, ISO standards, ISO/IEC 9126 standard, maintainability, probabilistic software quality model, probability, risk estimation, select:quality, software change, software maintenance, software quality, software quality selected},
	issn = {1063-6773},
	doi = {10.1109/ICSM.2011.6080791},
	author = {Tibor Bakota and P Heged{\H u}s and K{\"o}rtv{\'e}lyesi, P and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
