2011-03-10 75 views
24

對於我的工作,我必須開發一個小型Java應用程序,用於解析非常大的XML文件(〜300k行)以選擇非常特定的數據(使用Pattern),所以我試圖優化一點。我想知道什麼是這兩個片段之間的更好:有什麼更好的?多條if語句,或者多條件條件之一

if(boolean_condition && matcher.find(string)) 
{ 
    ... 
} 

OR

if(boolean_condition) 
{ 
    if(matcher.find(string)) 
    { 
     ... 
    } 
} 

更多精度:

  • 這些if語句在每個迭代循環內執行(〜 20k迭代)
  • boolean_condition是一個boolean計算遲來使用
  • 如果boolean設置爲false外部函數每次迭代中,我並不需要測試的正則表達式匹配

感謝您的幫助

+0

沒有簡單的答案。看看[本SO討論](http://stackoverflow.com/questions/1928712/how-to-split-up-complex-conditions-and-keep-short-circuit-evaluation)關於同一主題。 – 2011-07-12 14:43:41

回答

42

一個金科玉律我跟隨是儘量避免嵌套。但如果這樣做的代價太複雜,我不會介意將它嵌套出來。

除了你正在使用短路&&運營商。所以如果布爾值爲假,它甚至不會嘗試匹配!

所以,

if(boolean_condition && matcher.find(string)) 
{ 
    ... 
} 

是要走的路!

+0

謝謝!我不確定運營商,如果它被設置爲false,匹配是否會執行。 – 3rgo 2011-03-10 13:05:04

+9

考慮'if(x!= null && x.isY())';如果'&&'*沒有*將評估短路,那麼這會使x == null空洞。 – 2011-03-10 13:13:51

+1

是的!但是,我必須肯定,所以我問 – 3rgo 2011-03-10 13:24:03

1

第一個。我試圖避免如果像這樣嵌套,我認爲這是糟糕的風格/醜陋的代碼,並且如果布爾值爲true,則會短路並且只用matcher.find()進行測試。

3

兩種方式都可以,如果第一種情況爲假,則不會測試第二種情況。

使用使代碼更具可讀性和可理解性的代碼。只有兩種情況,第一種方式更具邏輯性和可讀性。對於與&&,||!鏈接的5或6個條件可能不再是這種情況。

2

Java對這些布爾運算符使用短路,所以這兩個變體在功能上是相同的。因此,如果boolean_condition是錯誤的,它將不會繼續進行匹配

最終,它歸結爲易於閱讀和調試的地方,但如果最終產生大量的牙套在年底就可以提高程序的可讀性

的一種方式,如果條件變得更長是簡單地將其拆分到多個行:

if(boolean_condition && 
    matcher.find(string)) 
{ 
    ... 
} 

在這一點上,唯一的選擇是,是否把& &和||在上一行的結尾,或當前的開始。

13

以下兩種方法:

public void oneIf(boolean a, boolean b) 
{ 
    if (a && b) 
    { 
    } 
} 

public void twoIfs(boolean a, boolean b) 
{ 
    if (a) 
    { 
     if (b) 
     {  
     } 
    } 
} 

產生的方法體完全相同的字節碼所以不會有任何性能差異意味着它是純粹的,你使用(我個人比較喜歡的一種風格件事第一種風格)。

+4

我不會知道是否該方法'公共無效noIfs(布爾一個,布爾b){}'產生的相同字節代碼太;-) – Axel 2011-03-10 13:23:35

+2

@Axel沒有,它沒有(我只是檢查!)真的不足爲奇,Java編譯器只做了很少的優化,將它留給JVM在運行時執行。 – Jonathan 2011-03-10 13:48:31

+0

我認爲解析器在第二個構造中有更多的工作要做,因爲它必須弄清楚下一個語句是'if'還是別的。另一方面,在第一個結構中,它只會解析條件,並知道以下是條件的一部分。 – kvaibhav 2016-12-20 04:22:51

1

在性能方面,它們是相同的。

  • 但即使他們不

什麼幾乎肯定會佔主導地位的時間在此代碼是matcher.find(string)因爲它是一個函數調用。

0

我往往看到太多& &和||串成一個邏輯湯,往往是微妙的錯誤的來源。

實在是太容易添加另一& &或||到你認爲正確的地方,並打破現有的邏輯。

因爲這作爲一般規則,我儘量不使用其中任何一個,以避免增加更多的需求改變的誘惑。

1

如果你喜歡被符合Sonar rule squid:S1066你應該崩潰if語句來避免警告,因爲它指出:

可摺疊的「if」語句應合併