Maintaining a program is the most time-consuming part of its development and there are actually more projects to maintain than those that start from scratch. Therefore, the software must also be designed to function correctly and efficiently enough so that future changes are as easy as possible to carry out. There are several reasons why software needs maintenance according to its categories:
Corrective: due to the need to correct errors.
Adaptive: by adaptation to a new environment or improvement with a new operating system or technologies.
Improvement: bug fixes or addition of new functionalities.
Preventive: to improve quality or prevent future errors.
In the book Building Maintable Software (Java Edition) in several chapters they review various aspects and provide advice on how to develop more easily maintainable software. Some are as simple as avoiding methods with many lines of code, with many parameters, with many branches by conditional or return statements. These aspects influence the ease of performing theses, the ease of reusing the code, being easier to test and reuse methods that do few things than others that do many or are complex. These aspects of the code require parsing the code.
What is PMD and what is it for?
If the software code base is large, it will be tedious and expensive to review it manually, however there are tools like PMD that allow us to automate the analysis task. PMD is a static code analysis tool that serves to verify that the code follows the style standards defined for the project or in an organization in addition to those other aspects that affect the ease of maintenance of the software, also useful when incorporating a new one person to a project to follow the rules already established. Just as you must have unit and integration theses to verify the correct operation of the software with PMD, a report is obtained with the violations of the rules that you want to apply when analyzing the code.
In the PMD project documentation in the Rule Reference section there are the rules that can be applied and configured in the analysis, there are a good number of them that in some cases allow modifying the thresholds or other properties to adapt the validation as desired. From conventions when formatting the code, use of keys, code size, comments, design, empty code blocks in try-catch , if ,… statements , duplicate imports , not used or from the same package and therefore unnecessary, unnecessary uses fully qualified names, variable nomenclature for example if they are too short or long, optimizations, unnecessary or unused code that can be removed.
The conventions and style guide for Java source code
When inheriting a new project whose maintenance is complicated and large because it does not comply with several of the previous rules, it is not possible to review all the code completely manually, you can guess what some of the problems are by reviewing some parts and suppose that in the rest They are also. A good step is to use PMD to accurately detect a good amount and correct them as changes are made to the code, with the passage of time maintenance if it is still difficult it will not be because there is unnecessary code, not used blocks of empty code or unused imports that are completely unnecessary and removable without risk.