NOBRAINER: A Tool for Example-Based Transformation of C/C++ Code
- PDF / 701,076 Bytes
- 11 Pages / 612 x 792 pts (letter) Page_size
- 53 Downloads / 179 Views
BRAINER: A Tool for Example-Based Transformation of C/C++ Code V. V. Savchenkoa,*, K. S. Sorokina,**, I. E. Bronshteina,***, A. S. Volkova,****, V. V. Kachanova,*****, G. A. Pankratenkoa,******, M. K. Ermakova,*******, S. I. Markova,********, A. V. Spiridonova,*********, and I. V. Aleksandrova,********** a
Ivannikov Institute for System Programming, Russian Academy of Sciences, Moscow, 109004 Russia *e-mail: [email protected] **e-mail: [email protected] ***e-mail: [email protected] ****e-mail: [email protected] *****e-mail: [email protected] ******e-mail: [email protected] *******e-mail: [email protected] ********e-mail: [email protected] *********e-mail: [email protected] **********e-mail: [email protected]
Received February 10, 2020; revised February 20, 2020; accepted March 15, 2020
Abstract—Refactoring is an integral part of the modern software development process. Often, the refactoring must be performed at the global level with modifications in a large number of files. Making these modifications is a long and painstaking work. However, users rarely employ automated tools for this purpose because they consider them unreliable and difficult to use. In this paper, a new tool for transforming the source code is described. It is based on the intuitively clear specification of transformation rules in the form of short code fragments in C or C++. These rules describe the code before and after the transformation. We believe that, due to the absence of additional abstractions (such as domain-specific languages), this approach can be easily used in practice. Even though the tool uses source code templates, it operates on the level of the abstract syntax tree. This enables the tool to better analyze the code and verify the validity of transformations. DOI: 10.1134/S0361768820040052
1. INTRODUCTION Any software product is evolving. The evolution in this case is not only the addition of new code implementing new functions but also continuous modification of the existing code. The excessive attention to the first aspect can result in the rapid accumulation of technical debt in the project. The technical debt [2] is a metaphor of software engineering that denotes simplifications in the architecture and code aimed at accelerating the initial development and deployment of the software product. If the technical debt is not paid off, it can, as time goes on, accumulate “interest”—the additional time needed for the developers to modify the program. In the worst case, the accumulated problems make the further development impossible. A standard method of overcoming this difficulty is refactoring [1, 12], which is a modification of the internal program structure that does not affect its
functionality [3]. Refactoring helps get rid of the existing architectural issues and simplify the program maintenance in future. According to Murphy-Hill estimates [8], software engineers spend 41% of their time on the refactoring-related activity. This paper also contains statistical data showing that developers prefer to
Data Loading...
