java命令行參數(shù)工具

在我的系列文章的前七篇文章中，有關(guān)處理Java方法中期望的參數(shù)過多的內(nèi)容集中在減少方法或構(gòu)造函數(shù)期望的參數(shù)數(shù)量的替代方法上。 在本系列的第八篇文章中，我將介紹一些工具，這些工具可幫助您確定可能存在過多參數(shù)的情況，以及有助于在出現(xiàn)這種情況時(shí)進(jìn)行處理的工具。

對于方法或構(gòu)造函數(shù)中過多的參數(shù)，實(shí)際上并沒有硬性規(guī)定 。 在許多方面，這都是一個(gè)問題，在一定程度上取決于這些參數(shù)是什么，它們是否使用自定義類型而不是原始類型和重復(fù)類型，以及是否存在可能需要傳遞null的可選參數(shù)。

羅伯特·馬丁 （ Robert Martin ）在《 清潔代碼》中寫道 （第40頁）：

函數(shù)的理想?yún)?shù)個(gè)數(shù)為零（尼拉度）。 接下來是一個(gè)（單聲道），緊接著是兩個(gè)（雙聲道）。 在可能的情況下，應(yīng)避免使用三個(gè)參數(shù)（三重性）。 超過三個(gè)（多義詞）需要非常特殊的理由-因此無論如何都不應(yīng)使用。

在《代碼完成》中 ， 史蒂夫·麥康奈爾 （ Steve McConnell）寫道，開發(fā)人員應(yīng)“將例程參數(shù)的數(shù)量限制為七個(gè)左右”，因?yàn)椤捌邆€(gè)是讓人理解的神奇數(shù)字?！?我不認(rèn)為有任何設(shè)定的最大參數(shù)數(shù)目，但是七個(gè)參數(shù)似乎似乎很少超過“經(jīng)驗(yàn)法則”，而且我通常更喜歡較小的數(shù)目，例如Martin建議的參數(shù)少于三個(gè)。

“眼睛測試”

體育談話和體育寫作中有一個(gè)共同的表達(dá)，即某些球員或球隊(duì)“沒有通過視力測驗(yàn)”。 我對這種表達(dá)的理解是，這意味著盡管有任何積極的統(tǒng)計(jì)數(shù)據(jù)可能與該球員或團(tuán)隊(duì)相關(guān)聯(lián)，但觀看球員或團(tuán)隊(duì)的比賽會讓人們相信他們并不如統(tǒng)計(jì)數(shù)據(jù)所示。 換句話說，以一種難以描述的方式，觀看者感覺到團(tuán)隊(duì)或球員并不像他們的統(tǒng)計(jì)數(shù)據(jù)所暗示的那樣熟練。

在許多方面，軟件開發(fā)都有其自己的“眼力測試”，可以告訴我們某些事情何時(shí)比“規(guī)則”所暗示的好或壞。 盡管如此，我們?nèi)匀粨碛嘘P(guān)于“規(guī)則”或一般性指導(dǎo)原則，以了解如何構(gòu)成良好的軟件習(xí)慣，就像體育比賽中有統(tǒng)計(jì)數(shù)據(jù)試圖客觀地對比球隊(duì)和球員一樣。 例如，在軟件中，我們可能會說“參數(shù)較少通常比更多參數(shù)要好。” Tooling的最大局限性在于它無法為我們執(zhí)行“眼力測試”，但可以幫助我們確定潛在的改進(jìn)領(lǐng)域。 換句話說，工具可以幫助報(bào)告游戲或比賽的“統(tǒng)計(jì)數(shù)據(jù)”，但是我們必須對工具所報(bào)告的內(nèi)容做出自己的判斷（“眼力測試”）。

靜態(tài)分析工具

靜態(tài)分析工具可用于自動識別可能期望太多參數(shù)的方法或構(gòu)造函數(shù)。 一旦確定了可能帶有太多參數(shù)的方法和構(gòu)造函數(shù)，開發(fā)人員便可以對其進(jìn)行“眼力測試”，以確定是否應(yīng)采取糾正措施。

PMD

PMD （帶有幽默的口號“ Do n't Shoot the Messenger”）是一個(gè)“源代碼分析器”，可以“發(fā)現(xiàn)”多種編程語言（包括Java）中的常見編程缺陷。 PMD的規(guī)則之一是“ ExcessiveParameterList ”（PMD 4.3中的LongParameterListRule而不是ExcessiveParameterList ）。 觸發(fā)此規(guī)則時(shí)， PMD提供的操作是“嘗試將參數(shù)分組在一起”和“應(yīng)創(chuàng)建一個(gè)新對象以包裝大量參數(shù)”（請參閱??我關(guān)于參數(shù)對象的文章 ）。 較新的PMD文檔這樣說：“具有眾多參數(shù)的方法很難維護(hù)，特別是如果大多數(shù)方法共享相同的數(shù)據(jù)類型時(shí)。 這些情況通常表示需要新對象來包裝大量參數(shù)?！?

任何工具都必須具有指定數(shù)量的被認(rèn)為“太多”的參數(shù)。 在PMD的情況下，該默認(rèn)數(shù)字為10。請注意，此觸發(fā)PMD規(guī)則的默認(rèn)最小閾值高于Steve McConnell建議的7個(gè)最大參數(shù)，并且大大高于Robert Martin建議的少于三個(gè)參數(shù)。

可通過PMD插件獲得NetBeans PMD支持 。 還可以通過軟件質(zhì)量環(huán)境插件獲得NetBeans PMD支持。 我在以前的文章NetBeans 7和軟件質(zhì)量環(huán)境以及在NetBeans 7中配置SQE插件中對此進(jìn)行了介紹。 QAPlug-PMD是用于IntelliJ IDEA的類似插件，而PMD Eclipse可用于Eclipse 。

Checkstyle

與PMD一樣， Checkstyle 會檢測并警告過多的方法和構(gòu)造函數(shù)參數(shù)。 Checkstyle在其主頁上定義為“一種開發(fā)工具，可幫助程序員編寫符合編碼標(biāo)準(zhǔn)的Java代碼。” 特別是，Checkstyle為ParameterNumber “ check ”提供了描述，“檢查方法或構(gòu)造函數(shù)的參數(shù)數(shù)量?！?在Checkstyle的情況下，構(gòu)造函數(shù)或方法的默認(rèn)“最大參數(shù)允許數(shù)量”為7（與Steve McConnell的建議相同）。

Checkstyle可以使用Checkstyle Beans插件與NetBeans結(jié)合使用。 與NetBeans PMD支持一樣，也可以通過前面提到的Software Quality Environment獲得NetBeans中的Checkstyle支持。 eclipse-cs插件支持將Checkstyle與Eclipse集成，而Checkstyle-IDEA是IntelliJ IDEA的類似插件。

CodePro Analytix

CodePro Analytix是Google Java開發(fā)人員工具的一部分 ，被描述為 “ Eclipse開發(fā)人員的首要Java軟件測試工具，他們關(guān)心提高軟件質(zhì)量，降低開發(fā)成本和進(jìn)度。” 它包括代碼審核功能，其中一類規(guī)則是“ 程序復(fù)雜性” 。 這些規(guī)則之一是“ 大量參數(shù) ”規(guī)則。 該規(guī)則的摘要是“方法不應(yīng)包含太多參數(shù)”，其描述為：“此審核規(guī)則將查找具有超過指定數(shù)量參數(shù)的方法。 超過此數(shù)目的方法可能太復(fù)雜。 考慮將與它們相關(guān)的某些價(jià)值和行為移到一個(gè)單獨(dú)的類中。”

還值得注意的是，CodePro Analytix還支持“平均參數(shù)數(shù)量”指標(biāo)用于指標(biāo)報(bào)告。 該度量標(biāo)準(zhǔn)報(bào)告每個(gè)方法的平均參數(shù)數(shù)量，但不包括構(gòu)造函數(shù)。

NetBeans Java代碼指標(biāo)提示

我已經(jīng)提到了用于Checkstyle和PMD的NetBeans插件，但是我在NetBeans中最喜歡的功能之一是眾多且高度可定制的內(nèi)置NetBeans提示和檢查 。 NetBeans 7.4引入了一個(gè)全新的提示類別，稱為“ Java代碼度量 ”，這些新提示之一是“構(gòu)造函數(shù)聲明了太多參數(shù)”提示。 此提示描述為：“使用太多參數(shù)的報(bào)表構(gòu)造函數(shù)。 構(gòu)造函數(shù)通常比常規(guī)方法采用更多的參數(shù)，尤其是在初始化大對象時(shí)。 大量參數(shù)表示設(shè)計(jì)不良。 將來可能還會添加更多參數(shù)，因此應(yīng)考慮使用諸如Builder之類的創(chuàng)建模式?！?在本系列的上一篇文章中，我介紹了構(gòu)建器模式的應(yīng)用，甚至討論了如何使用NetBeans重構(gòu)構(gòu)建器。

另一個(gè)新添加的提示“ Method聲明了太多參數(shù)”被描述為“ Reports方法使用了太多參數(shù)”。 具有大量參數(shù)的方法表明設(shè)計(jì)不良。 將來可能還會添加更多參數(shù)，因此應(yīng)將這些參數(shù)分組到一個(gè)Command Object中，從而降低維護(hù)成本。 另外，該方法可以重構(gòu)為幾種方法，每種方法都完成一部分任務(wù)，并且在輸入時(shí)需要較少的參數(shù)?！?推薦的方法本質(zhì)上與我在本系列文章的前面博客中提到的參數(shù)對象方法相同。

默認(rèn)情況下，NetBeans 7.4的“ Java代碼度量”類別中的所有提示均被禁用。 在他的博客文章“ 我的代碼到底有多混亂？ ”，“偶爾”的NetBeans博客Geertjan Wielenga演示了如何配置Java Code Metrics使其處于活動狀態(tài)。

下一個(gè)屏幕快照演示了NetBeans 7.4中Java Code Metrics的使用。 通過選擇“源”，然后選擇“檢查...”（將打開NetBeans 7.4“檢查”窗口）進(jìn)行配置。

在“檢查”窗口中選擇“使用”標(biāo)簽和“配置”項(xiàng)目符號旁邊的下拉菜單時(shí)，可以使用下一個(gè)屏幕快照中指示的選項(xiàng)。

出于演示目的，我選擇“所有分析”，然后單擊“檢查”按鈕。 下一個(gè)屏幕快照演示了正在進(jìn)行的檢查/分析。

NetBeans Inspect機(jī)制“開箱即用”，發(fā)現(xiàn)一堆我的代碼缺少Javadoc語句，但是沒有用太多參數(shù)來標(biāo)記構(gòu)造函數(shù)和方法。 為了解決這個(gè)問題，我需要遵循Geertjan博客文章中的步驟。 為此，我可以單擊Source | 檢查并將“配置”選擇為“默認(rèn)”。

選擇“默認(rèn)”使我現(xiàn)在可以單擊“管理...”按鈕，然后單擊該按鈕將顯示“配置”窗口。

單擊“默認(rèn)”標(biāo)簽會導(dǎo)致一個(gè)下拉菜單，從中可以選擇“新建...”。

我可以將新配置命名為“ Java Code Metrics”。

單擊“分析器”標(biāo)簽旁邊的下拉菜單，可以選擇“ NetBeans Java提示”，然后選擇該選項(xiàng)可以按類別顯示所有NetBeans Java提示。 下一個(gè)屏幕快照顯示了我可以選擇要檢查的代碼度量。

下一個(gè)屏幕快照指示我可以選擇“構(gòu)造函數(shù)聲明太多參數(shù)”作為復(fù)選框，而選擇“方法聲明太多參數(shù)”作為另一個(gè)復(fù)選框。

通過新的“ Java代碼度量”檢查，現(xiàn)在可以通過單擊“檢查”按鈕輕松檢查那些特殊問題。

按下“檢查”以應(yīng)用新創(chuàng)建的“ Java代碼度量”檢查，將在以下屏幕快照中顯示結(jié)果。 第一個(gè)圖像顯示了高級結(jié)果，隨后的圖像顯示了通過單擊高級結(jié)果而提供的更多詳細(xì)信息。

使用我所介紹的所有靜態(tài)分析工具，對于一個(gè)構(gòu)造函數(shù)或方法，可以調(diào)整被認(rèn)為“太多”的參數(shù)數(shù)量。 借助NetBeans的Java Code Metrics支持，此配置確實(shí)非常容易。 接下來的兩個(gè)屏幕快照展示了分別在我們要檢查的選項(xiàng)所在的同一窗口中為構(gòu)造函數(shù)和方法設(shè)置了這些值的情況。 每個(gè)選中的選項(xiàng)的擴(kuò)展窗口包括檢查類型的定義和用于選擇適用參數(shù)數(shù)量的字段。

能夠輕松更改被認(rèn)為不可接受的參數(shù)數(shù)量（或至少值得指出以便可以應(yīng)用“眼力測試”）是一件好事，因?yàn)閷τ诓豢山邮艿臄?shù)量存在如此廣泛的意見。

如最后一系列屏幕快照所示，NetBeans 7.4允許我們專門檢查代碼中“參數(shù)太多”的方法和構(gòu)造函數(shù)。 在撰寫本文的這一部分時(shí)，我想起了NetBeans提供了重要的靜態(tài)代碼分析支持 。

IntelliJ IDEA檢查

IntelliJ IDEA提供了檢查以找出具有過多參數(shù)的方法。 “ 參數(shù)過多的方法 ”檢查描述為：“此檢查報(bào)告參數(shù)過多的方法的所有實(shí)例。 參數(shù)過多的方法表明必須進(jìn)行重構(gòu)。 其簽名是從庫類繼承的方法將被此檢查忽略?！?此檢查允許配置的方法參數(shù)數(shù)量過多。

其他靜態(tài)分析工具

除了我已經(jīng)集中討論的工具以外，還有其他工具可以通過靜態(tài)分析在Java方法或構(gòu)造函數(shù)接受“參數(shù)過多”時(shí)進(jìn)行標(biāo)識和標(biāo)記。 其中包括Java Coding Standard Checker和Sonar 。 所有這些識別“參數(shù)太多”的靜態(tài)分析工具的存在證明了參數(shù)太多可能是維護(hù)和可讀性的問題。

代碼變更工具

到目前為止，本文中討論的工具在分析代碼以查找期望參數(shù)過多的現(xiàn)有方法和構(gòu)造函數(shù)方面非常有用。 一旦確定，就可以手動更改/重構(gòu)這些構(gòu)造函數(shù)和方法，以減少參數(shù)的數(shù)量，例如我在本系列過多參數(shù)系列的較早文章中概述的方法。 幸運(yùn)的是，有一些工具可以幫助進(jìn)行這些重構(gòu)和新的代碼生成工作。 現(xiàn)代Java IDE在重構(gòu)和代碼生成方面特別有用。

重構(gòu)

構(gòu)造器的應(yīng)用程序是我處理構(gòu)造器參數(shù)過多的最喜歡的方法之一。 幸運(yùn)的是，NetBeans能夠依靠大量參數(shù)構(gòu)造函數(shù)來自動重構(gòu)代碼以使用構(gòu)建程序?qū)崿F(xiàn)。 我以前在“ Java方法中的參數(shù)太多，第3部分：構(gòu)建器模式和NetBeans 7.2：將參數(shù)化構(gòu)造函數(shù)重構(gòu)為Builder”中發(fā)表了關(guān)于此方法的博客。 IntelliJ IDEA有一個(gè)類似的重構(gòu)工具，稱為Builder 。 Builder Pattern Eclipse插件可用于Eclipse。

代碼生成

我最喜歡的處理太多參數(shù)的方法包括編寫新的自定義類型和創(chuàng)建參數(shù)對象 。 現(xiàn)代Java IDE在這里非常有用，可以簡化這些類和枚舉的生成。 通常只需幾分鐘即可生成具有適當(dāng)?shù)膖oString（） ， hashCode（）和equals（Object）實(shí)現(xiàn)的完整類。 很難說，鑒于使用現(xiàn)代Java IDE及其代碼生成功能編寫自定義類型類和參數(shù)對象（命令）類太容易了，因此編寫自定義類型類和參數(shù)對象（命令）類太“昂貴”。

結(jié)論

這篇文章的重點(diǎn)是Java開發(fā)人員可以用來在Java代碼中識別方法和/或構(gòu)造函數(shù)期望太多參數(shù)的位置的工具，以及可以輕松地修復(fù)這些構(gòu)造函數(shù)和方法以接受更合理數(shù)量的Java工具的可用工具。參數(shù)。 有幾種靜態(tài)分析工具和IDE支持對期望過多參數(shù)的構(gòu)造函數(shù)和方法的快速識別，而現(xiàn)代Java IDE使重構(gòu)和代碼生成變得輕松快捷。 可用于識別“太多參數(shù)”問題的大量工具提醒我們，這實(shí)際上是一個(gè)值得解決的問題。

參考： Java方法中的參數(shù)太多，第8部分：來自JCG合作伙伴 Dustin Marx的工具，來自Inspired by Actual Events博客。

翻譯自: https://www.javacodegeeks.com/2013/11/too-many-parameters-in-java-methods-part-8-tooling.html

java命令行參數(shù)工具

總結(jié)

以上是生活随笔為你收集整理的java命令行参数工具_Java方法中的参数太多，第8部分：工具的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。