2014-01-10 1 views
5

Этой часть коды отвергается PMD в гидролокаторе:Избегайте литералы Если условие

public String getFoo() { 
    String foo = System.getProperty("foo"); 

    if (foo == null) { 
     foo = System.getenv("foo"); 
    } else if (foo == null) { 
     foo = "defaultFoo"; 
    } 

    return foo; 
} 

Он говорит: «Избегайте литералы Если условие». Может кто-нибудь сказать мне, что не так с этим или что это правило пытается добиться?

+1

кстати второй, если это абсолютно бесполезно, так как вы пытаетесь проверить то, что было проверено, прежде чем – ITroubs

+1

Избегайте использования жестко закодированные литералы в условных операторах, объявить их в качестве статических переменных или частных пользователей. – Kick

+1

Я отредактировал вопрос и удалил неотправленную часть, потому что ответы все сфокусированы на неправильную часть. –

ответ

3

Что Сонар пытается сказать, что вам следует избегать жестко закодированных литералов (например, null) в состоянии if.

Пусть следующий пример:

Допустим, у нас есть это if заявление, в котором Sonar предупреждает с Избегайте литералов Если условие:

if (i == 5) { 
    //do something 
} 

Объявив жёстко буквальным, как (final) с улучшенной эксплуатационной характеристикой описательных имен:

final int FIVE = 5; 
if (i == FIVE) { 
    //do something 
} 

и Sonar больше не предупреждают.

+0

Как объявить нуль как конечную переменную? –

+0

Как насчет 'final Object NULL = null;'? –

+3

Да, это причина. Но в этом случае я думаю, что я удалю это правило. –

6

Почему бы вам не использовать:

public String getFoo() { 
    String foo = System.getProperty("foo", "defaultFoo"); 

    return foo; 
} 

Он вернется "defaultFoo" если нет свойство не найдено.

http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#getProperty(java.lang.String, java.lang.String)

+1

Вопрос фокусировался на том, почему правило pmd не совместимо. Но +1, потому что это тоже хорошая идея. –

 Смежные вопросы

  • Нет связанных вопросов^_^