inCode: Continuous Quality Assessment and Improvement Radu Marinescu, George Ganea and Ioana Verebi LOOSE Research Group Politehnica University of Timis ¸oara, Romania Abstract—While significant progress has been made over the last ten years in the research field of quality assessment, developers still can’t take full advantage of the benefits of these new tools and technique. We believe that there at least two main causes for this lack of adoption: (i) the lack of integration in mainstream IDEs and (ii) the lack of support for a continuous (daily) usage of QA tools. In this context we created INCODE as an Eclipe plugin that would transform quality assessment and code inspections from a standalone activity, into a continuous, agile process, fully integrated in the development life-cycle. But INCODE not only assesses continuously the quality of Java systems; it also assists developers in taking restructuring decisions, and even supports them in triggering refactorings. I. I NTRODUCTION The typical usage scenario of a QA module/methodology is currently this: a developer, feeling that something is wrong with the design/code, is using the QA module provided by (or available for) her IDE to compute a suite of metrics; noticing some abnormal metric values, she must infer what the real design problem is from the informal description of the metric’s interpretation model. This is not easy at all, es- pecially when the analysis occurs long after that code/design fragment has been created, and/or the code was written by someone else. But even after finding out what the problem is, correcting the design flaws moves the developer to another world, where she must compose the proper restructuring solution using the basic refactorings available in her IDE. This is again a challenging and painstaking operation. We believe that this process is so tedious because of two reasons: (i) metrics used to detect design flaws are only “detection atoms”, and, therefore incapable of pointing out to relevant correction (restructuring) solutions; (ii) refactorings, as they are used know, are also only the “correction atoms”, and therefore they don’t represent the correction solution for all but non-trivial design problems. With INCODE we propose a novel type of QA tools, with the following (agile) “manifesto”: (i) Continuous detection and correction of design flaws, instead of standalone, post- factum (or even “post-mortem”) code inspections; (ii) Ex- posure of real design flaws, instead of displaying abnor- mal metrics values; (iii) Contextual, problem-driven, tool- assisted restructuring strategies, instead of a repetitive (ad- hoc) composition of restructuring solutions from atomic refactorings. Next we are going to briefly introduce (some of) the main features of INCODE i.e., those that reveal its novelty. II. CONTINUOUS DETECTION OF DESIGN PROBLEMS INCODE is an Eclipse plugin in which design problems are detected continuously. When the Eclipse workbench starts, INCODE also starts to analyze (in background) the source file currently active in the editor. When a design problem is detected, a red marker is placed on the ruler, next to the affected class or method (and also in the overview ruler on the right side of the editor). The inCode markers are similar to the markers used for compiler errors or warnings (see Figure 1). The presence of these markers is very dynamic: as new code is written, or code is modified new markers may appear, or existing markers may disappear. Figure 1. INCODE marks automatically, and updates continuously, code entities with design problems As mentioned before, we believe that metrics used in isolation cannot help in detecting real design problems. Therefore, in INCODE we use detection strategies [1] to quantify design problems [2]. Currently INCODE detects four design problems related to an improper distribution of intelligence among classes. Specifically these are: God Class, Data Class, Feature Envy and Code Duplication [3], [4]. Thus, while the detection is based on object-oriented metrics, developers don’t have to interact directly with metrics. Instead, they can reason about the quality of their design at the conceptual level that is more convenient for them. III. CAUSES AND CURES FOR EACH DESIGN PROBLEM In order to see the details about what caused a class/method to be detected as having a particular design problem, the user clicks on the red marker and selects the