I want to reduce the number of sonar violations in a large legacy java code-base, and it seems a "quick win" would be to update all these conditional statements to have curly brackets. This seems like an easy thing to do and I can't see why it wouldn't be readily automatable.
Does anybody know of a tool that could perform a bulk operation like this? Or why to do such a thing might be a bad idea before I go and spend the time writing something myself? If I were to write one myself what would be the best tools to use? Ideally something that is java language aware, so that I don't have to deal with formatting corner-cases and the like.
The rule is non-negotiable by the way, so this really is the best approach.
Interesting.
You have a legacy codebase that is full of style errors, AND it is not negotiable that the style errors must be fixed.
The value proposition of this exercise is (to say the least) dubious. "Legacy codebase" is often a polite way of say that the code ought to be thrown away and rewritten ... but you can't afford it. However, apparently, you can afford to spend correcting missing braces, which is unlikely to make any real difference to maintainability.
As previous answers point out. If you automate this style correction properly:
It won't actually fix any bugs but it won't introduce any new ones either.
It might remove "clues" (e.g. dubious indentation) that are would be flags for existing bugs.
But if you do the style corrections manually:
There is a chance that you will notice some bugs. These can be added to your issue tracker for further diagnosis and fixing.
There is also a chance that you will introduce new bugs. And if we assume that the existing unit / systems are non-existent or of low quality (this is a legacy codebase) then these new bugs have a fair chance of going undetected.
Now generalize across style-related errors that Sonar detects.
In summary, this whole process of fixing all of the style errors in a legacy codebase is (IMO) largely a waste of time if automated, and possibly risky if manual.
This should be negotiable. You should be able to tell management of these concerns ...
Intellij 2017 support this with Reformat Code, if you set the right coding style in the editor settings first.
While it may be a quick sonar win, you are doing some dangerous stuff. The recommended approach is to only fix legacy code when that code has to be revisited. These blanket approaches are going to potentially cause very subtle bugs. Because policy has changed your management team needs to understand that this is a massive undertaking, and should guarantee that all future code is developed to the standard.
The easiest thing would be to use Eclipse and click
Clean-up
on the whole project. InClean-up
profile configuration selectCode style
tab. There you can selectUse blocks in if/while/for/do statements
asAlways
.Robert in a comment said: "@ira i would also be interested in hearing of this truly language aware tool!"
Sorry for the tease. For the cause of the tease, check my bio.
Untease: see http://www.semanticdesigns/Products/DMS/DMSToolkit.html as the foundation engine, and http://www.semanticdesigns.com/Products/FrontEnds/JavaFrontEnd.html. The pair make a fully language aware source-to-source program program transformation system.
One would accomplish this task with DMS with two source-to-source transformation rules:
This works reliably because DMS is driven completely from a formal grammar (for Java in this case), and is not operating on raw text, but rather abstract syntax trees; this also makes in independent of layout. (It is probably useful to understand the rules that "block", "expression" and "statement" are grammar nonterminals.
First enable
Control flow statement without braces
in the inspection settings.IntelliJ Idea -> Run Code Inspection -> Quick Fix (works at least in the commercial version)