Sonarlint程式碼規範改造實踐及一些想法

1.Ternary operators should not be nested（三元運算子不應該巢狀）

官方給的原因：
僅僅因為您可以做一些事情，並不意味著您應該做，巢狀三元操作就是這種情況。巢狀三元運算子所生成的程式碼在您編寫時可能看起來非常清晰，但六個月後將會讓維護者(或者更糟——將來的您)撓頭咒罵。
相反，為了清晰起見，應該使用另一行將巢狀操作表示為單獨的語句。

這個規則我有些不認同，感覺有些沒必要改。

2. Instance methods should not write to “static” fields（例項方法不應該寫入“靜態”欄位）

官方給出的原因是：
從非靜態方法正確更新靜態欄位需要技巧，如果有多個類例項和/或多個執行緒在執行，則很容易導致錯誤。理想情況下，靜態欄位只從同步靜態方法中更新。
但是，我這個是藉助@PostConstruct註解的，如果再另起一個類做，感覺程式碼量又上來了，暫時先壓著，以後再考慮。

3. Cognitive Complexity of methods should not be too high（方法的認知複雜性不應過高）

認知複雜性是一種方法的控制流程難以理解的衡量標準。認知複雜性高的方法將難以維持。
嗯，這個…一言難盡

4. Utility classes should not have public constructors（實用程式類不應該有公共建構函式）

實用程式類是靜態成員的集合，並不意味著要例項化。即使是可以擴充套件的抽象實用程式類，也不應該有公共建構函式。
Java將隱式公共建構函式新增到每個沒有至少顯式定義一個的類中。因此，至少應該定義一個非公共建構函式。
嗯，這個感覺有沒有都沒多大所謂吧。

5. Resources should be closed（應該關閉資源）

實現可關閉介面或其超介面AutoCloseable的連線、流、檔案和其他類在使用後需要關閉。而且，必須在finally塊中完成這個差一點的呼叫，否則可能會出現異常使呼叫無法進行。最好，當類實現AutoCloseable時，應該使用“try-with-resources”模式建立資源，並自動關閉。

這個感覺還是很重要的。

未完待續