Practice and some ideas on the transformation of sonarlint code specification

Sonarlint Code specification transformation practice and some ideas

1.Ternary operators should not be nested（ Ternary operators should not be nested ）

Official reasons ：
Just because you can do something , Doesn't mean you should do , This is the case with nested ternary operations . The code generated by nested ternary operators may look very clear when you write , But in six months' time, the maintainer ( Or worse —— You in the future ) Scratch your head and swear .
contrary , For the sake of clarity , Another line should be used to represent the nested operation as a separate statement .

I don't agree with this rule , I don't think it's necessary to change something .

2. Instance methods should not write to “static” fields（ Instance methods should not write “ static state ” Field ）

The official reason is ：
Updating static fields correctly from non static methods requires skill , If there are multiple class instances and / Or more threads are running , It can easily lead to errors . Ideally , Static fields are only updated from synchronous static methods .
however , I use this with the help of @PostConstruct Annotated , If you create another class to do , I feel that the amount of code is coming up again , Hold it down for a while , Think about it later .

3. Cognitive Complexity of methods should not be too high（ The cognitive complexity of the method should not be too high ）

Cognitive complexity is an incomprehensible measure of a method's control process . Methods with high cognitive complexity will be difficult to maintain .
Um. , This … It 's a long story

4. Utility classes should not have public constructors（ Utility classes should not have public constructors ）

Utility classes are collections of static members , It doesn't mean instantiating . Even abstract utility classes that can be extended , Nor should there be a public constructor .
Java Add an implicit public constructor to every class that does not explicitly define at least one . therefore , At least one non-public constructor should be defined .
Um. , It doesn't matter whether this feeling exists or not .

5. Resources should be closed（ Resources should be closed ）

The implementation can close the interface or its super interface AutoCloseable The connection of 、 flow 、 Files and other classes need to be closed after use . and , Must be in finally Block to complete this near call , Otherwise, an exception may occur that makes the call impossible . best , When a class implements AutoCloseable when , You should use “try-with-resources” Patterns create resources , And turn it off automatically .
If the resource cannot be closed properly , Will lead to resource leakage , First, it will crash the application , Then the machine may be paralyzed .

This feeling is still very important .

To be continued