聲納：更好的規則爲java項目

我想找到一個更好的替代默認java質量配置文件「與Findbugs聲納方式」。聲納：更好的規則爲java項目

在配置文件的516條規則中，其中一些規則實際上沒有正確設置（優先級或激活）。

例如：

是「死存儲到本地變量」真正的關鍵問題？
「添加空字符串」被禁用，但值得啓用。
「使用等於比較字符串」已禁用...

，因爲我無法找到任何準備使用的一套規則，而不是默認的一個更好的，我想獲得有關這個主題的反饋來自有經驗的Sonar用戶。

來源

2012-10-09 ochedru

「死亡存儲到本地變量」真的是一個關鍵問題？

這可能是一個嚴重的問題，因爲它不僅僅表明在某些情況下浪費了內存。通常，這個問題是由於缺少或錯誤的變量訪問引起的。考慮下面這個例子中，m_valueY將被標記爲死存儲：

public class ResultData { 
    private int m_valueX; 
    private int m_valueY; 

    public int getValueX() { 
    return m_valueX; 
    } 
    public int getValueY() { 
    //should actually be m_valueY 
    return m_valueX; 
    } 
    public void setValueX(int valueX) { 
    m_valueX = valueX; 
    } 
    public void setValueY(int valueY) { 
    m_valueY = valueY; 
    } 
}

使用等於比較字符串

也許規則「的對象應該用‘的equals（）’相比，」是不是積極和隱含地涵蓋了這一問題所發現的問題。

來源

2015-03-06 08:45:43 nrainer

我的經驗（我使用的是SQ，因爲在3名不同的公司其第一個版本，寫了多年來130+定製檢查）如下：

創建一個配置文件P1是當前的一個副本「SonarQube Way」配置文件
刪除與您的上下文無關的所有規則（大多數情況下，如果您的自定義規則與現成規則衝突），並在需要時更改優先級（只嘗試增加優先級上下文需要它。）跟蹤修改配置文件的原因。這裏的要點是能夠說「除了一些我們想要更嚴格控制的特定情況外，我們遵循現成的配置」。此配置文件將用於輕鬆比較您當前的「SonarQube方式」配置文件和更新的配置文件。
創建一個配置文件P2，繼承自P1並添加其他規則，無論它們是否自定義。與您的開發團隊共同研究這個主題，以達成共識。
儘可能地保持您添加的規則的默認優先級（不要爲想要爭辯您的配置存在缺陷的人提供食物，並且如果您需要更改優先級，請準備好捍衛您的決定，請參閱下一頁）
對於所有規則優先級更改（現成規則和/或自定義規則），請遵循預定義的比例（例如this one）並遵守它。
使P2成爲默認配置文件。

然後每次「SonarQube Way」發展，您都可以輕鬆更新它，然後將其與P1進行比較。

您可以使用「SonarQube路與FindBugs的」個人資料做同樣的（但我不會這麼做，因爲這使得大量的規則...）

始終牢記，這是最好少你可以解釋規則，所有的開發者都願意申請，而不是有很多難以解釋，沒有人相信和沒人願意申請的檢查，也不會因爲大量的檢查而讀SQ。換句話說，從小開始，並與您的開發人員共同成長。

還記得那些不固定的問題（並且由於他的規則提高了太多的誤報，很難理解等原因，所以沒有人願意解決）是一個難以擺脫的債務。這是一個總會帶來更多債務的泄漏，主要是因爲人們還沒有準備好聽到這些問題。在這樣的情況下，最好停用這些規則，並在人們準備好談論它們並應用它們時再回來。

最後但並非最不重要。同意質量配置文件發佈日期的開發團隊。例如，假設您同意每年會有兩次配置文件更新。在兩個配置文件發佈之間，歡迎大家討論規則，但是直到下一個發佈之前這些規則都不會被修改，如果需要修改（添加/刪除規則），必須討論並找到一致意見。如果項目在兩個版本之間啓動，它將從當前配置文件開始並使用它。在更新配置文件時，您的項目可能有一個版本將其代碼與新規則對齊，或者如果您使用「修復泄漏」方法，則項目同意新代碼以及重構代碼將遵循新配置文件。

請記住，如果你的配置文件的擁有者，你的開發人員應該要添加要求新規則的人（這是由一條好KPI）。

還有很多東西要說這個，但這應該是一個很好的起點，以幫助你。

來源

2015-11-24 14:05:26 Kraal

聲納：更好的規則爲java項目

回答

相關問題