sonar 代碼質量檢查問題分析(二)


sonar 代碼質量檢查問題分析(二)


Mutable fields should not be "public static"

可變字段不應該是public static

不合規

<code>public interface MyInterface {
public static String [] strings; // Noncompliant
}

public class A {
public static String [] strings1 = {"first","second"}; // Noncompliant
public static String [] strings2 = {"first","second"}; // Noncompliant
public static List<string> strings3 = new ArrayList<>(); // Noncompliant
// ...
}/<string>/<code>

合規

<code>private static final String [] COLUMN_NAMES = new String[]{"date","customerNumber","customerName",
"account","emailAdress","mobilePhoneNumber","emailStatus"};

public static List<string> getColumnNames() {
return Collections.unmodifiableList(Arrays.asList(COLUMN_NAMES));
}/<string>/<code>

問題分析

請注意,使可變字段(例如數組)為final將阻止重新分配變量,但這樣做不會影響數組內部狀態的可變性

可以改變的類型如果非常有必要聲明為 ‘public static’ 可以通過上述 Collections.unmodifiableList 方式實現。


"public static" fields should be constant

  • public static 屬性應是常量


合規代碼

<code>public class Greeter {
public static Foo foo = new Foo();
public static String realmOplate = "this is name";

...
}
/<code>

不合規代碼

<code>public class Greeter {
public static final Foo FOO = new Foo();
...
}
private static String realmOplate = "this is name";
public static String getRealmOplate() {
return realmOplate;
}
public static void setRealmOplate(String realm) {
realmOplate = realm;
}/<code>

分析

在大多數情況下,public static 在多個對象之間共享狀態的一種期望。但是使用這種方法,任何對象都可以在共享狀態下做任何想做的事情,例如將其設置為null。

只有設置為了final時才會防止共享值被修改。

Class variable fields should not have public accessibility

  • 類中的成員屬性不應該共有訪問。


不合格代碼

<code>public class MyClass {

public static final int SOME_CONSTANT = 0; // Compliant - constants are not checked

public String firstName; // Noncompliant

}
/<code>

合規代碼

<code>public class MyClass {

public static final int SOME_CONSTANT = 0; // Compliant - constants are not checked

private String firstName; // Compliant

public String getFirstName() {
return firstName;
}

public void setFirstName(String firstName) {
this.firstName = firstName;
}

}
/<code>

問題分析

公共類變量字段不遵守封裝原理,並且具有三個主要缺點:
無法添加其他行為,例如驗證。
內部表示形式已公開,以後不能更改。
成員值可能會在代碼中的任何位置發生更改,並且可能不符合程序員的假設。

通過使用私有屬性和訪問器方法(設置和獲取),可以防止未經授權的修改。

Invoke method(s) only conditionally


不合規代碼

<code>logger.log(Level.DEBUG, "Something went wrong: " + message); 
// Noncompliant; string concatenation performed even when log level too high to show DEBUG messages/<code>

合規代碼

<code>logger.log(Level.DEBUG, "Something went wrong:{} ",message)/<code>

分析
日誌在輸出的情況下支持一個字符串輸出,沒有必要通過+生成多個字符串,浪費性能。


"toString()" and "clone()" methods should not return null

不合規代碼

<code>public String toString () {
if (this.collection.isEmpty()) {
return null; // Noncompliant
} else {
// ...
@Override
public Object clone() {
try {
return (ContractQuery) super.clone();
} catch (CloneNotSupportedException e) {
}
return null;
}/<code>

合規

<code>public String toString () {
if (this.collection.isEmpty()) {
return "";
} else {
// ...
@Override
public Object clone() throws CloneNotSupportedException {

return (ContractQuery) super.clone();
}
/<code>

分析

當toString clone 返回Null時,容易產生空指針問題。

Modifiers should be declared in the correct order

Java 語言中修飾符的位置順序。

1. Annotations

2. public

3. protected

4. private

5. abstract

6. static

7. final

8. transient

9. volatile

10. synchronized

11. native

12. strictfp

不合規代碼

<code>public final static String HOME= "home";/<code>
sonar 代碼質量檢查問題分析(二)

合規代碼

<code>public static final String HOME = "home";/<code>

分析

應根據約定俗稱的規範進行編碼,代碼不僅僅是給機器用,但卻是給人看的。寫給機器的能用的不叫本事,寫出人人都看的懂的才是能耐。


"@Deprecated" code should not be used

所以聲明過期的方法,類都有與之對應的代替方式。

反射中常用的

<code>//newInstance() 已過期
ContractDto contract = contractClass.newInstance();
//代替方式
contractClass.getDeclaredConstructor().newInstance()/<code>

Parentheses should be removed from a single lambda input parameter when its type is inferred

lambda 表達式中一個輸入參數沒有必要加括號

不合規代碼

<code>(x) -> x * 2/<code>

合規代碼

<code>x -> x * 2/<code>

總結

代碼編程長路漫漫,吾將上下而求索。使用sonar改進代碼,漂亮的代碼令人嚮往,猶如一位漂亮精緻的姑娘,讓人目不轉睛,愛不釋手。


sonar 代碼質量檢查問題分析(二)


做個有追求的程序員還是有必要的。



分享到:


相關文章: