PMD - сложность NPath очень высокая с троичным оператором (? - PullRequest
Новая
       5

PMD - сложность NPath очень высокая с троичным оператором (?

14 голосов
/ 22 февраля 2011

Я использую PMD для создания отчета о качестве кода в проекте.
Я не понимаю результат для проверки сложности NPath.
Я создал унылый класс, который демонстрирует результат (это не настоящий класс, но он использует тот же шаблон): 

import java.util.*;

public class SOFExample {

    private final Map<String, Date> magicMap = new HashMap<String, Date>();    
    protected static final long UNKNWOWN = 0L;
    private static final class MyCal { long aTime; long bTime; long cTime; long dTime;}

    public void usefullMethod(final List<MyCal> myCals) {

        final Date a = magicMap.get("a");
        final Date b = magicMap.get("b");
        final Date c = magicMap.get("c");
        final Date d = magicMap.get("d");

        final long aTime = a == null ? UNKNWOWN : a.getTime();
        final long bTime = b == null ? UNKNWOWN : b.getTime();
        final long cTime = c == null ? UNKNWOWN : c.getTime();
        final long dTime = d == null ? UNKNWOWN : d.getTime();

        for (MyCal myCal : myCals) {
            if(myCal.aTime == UNKNWOWN) myCal.aTime = aTime;
            if(myCal.bTime == UNKNWOWN) myCal.bTime = bTime;
            if(myCal.cTime == UNKNWOWN) myCal.cTime = cTime;
            if(myCal.dTime == UNKNWOWN) myCal.dTime = dTime;
        }
    }
}

PMD результат:

Метод usefullMethod () имеет сложность NPath 10625

Если я добавлю новую переменную, инициализированную таким же образом, я получу это:

Метод usefullMethod () имеет сложность NPath 103125

А если я все заменю? Со структурой if-else я получил это:

Метод usefullMethod () имеет сложность NPath 1056

Почему я получил этот очень высокий результат с троичным '?' Оператор?

Что не так с этим кодом? (В этом демонстрационном коде легко извлечь метод для получения значений по умолчанию, но в реальном коде это может быть невозможно)

1 Ответ

20 голосов
/ 27 февраля 2011

Делая пример еще проще, этот класс имеет значение nPath 2. Должно быть совершенно очевидно, почему его два - в коде явно два пути выполнения. 

package test;

import java.util.*;

public class Test {

    private static final long UNKNWOWN = -1;

    public void method(Date a) {
        long aTime;

        if (a == null) {
            aTime = UNKNWOWN;
        } else {
            aTime = a.getTime();
        }
    }
}

И этот класс имеет значение nPath, равное 5. Вопрос в том, почему в коде все еще есть два логических пути. 

package test;

import java.util.*;

public class Test {

    private static final long UNKNWOWN = -1;

    public void method(Date a) {
        final long aTime = a == null ? UNKNWOWN : a.getTime();
    }
}

Однако алгоритм используется следующим образом: 

int npath = complexitySumOf(node, 0, data);     
npath += 2;

Добавляет сложность для всех детей, затем добавляет двоих для троичной. Минимальная сложность, возвращаемая для простых java-узлов, равна 1. AbstractSyntaxTree показывает, что есть три дочерних элемента. Следовательно, 3 + 2 равно 5. 

<ConditionalExpression beginColumn="36" beginLine="11" endColumn="69" endLine="11" ternary="true">
  <EqualityExpression beginColumn="36" beginLine="11" endColumn="44" endLine="11" image="==">
    <PrimaryExpression beginColumn="36" beginLine="11" endColumn="36" endLine="11">
       <PrimaryPrefix beginColumn="36" beginLine="11" endColumn="36" endLine="11">
         <Name beginColumn="36" beginLine="11" endColumn="36" endLine="11" image="a"/>
       </PrimaryPrefix>
    </PrimaryExpression>
    <PrimaryExpression beginColumn="41" beginLine="11" endColumn="44" endLine="11">
      <PrimaryPrefix beginColumn="41" beginLine="11" endColumn="44" endLine="11">
        <Literal beginColumn="41" beginLine="11" charLiteral="false" endColumn="44" endLine="11" floatLiteral="false" intLiteral="false" singleCharacterStringLiteral="false" stringLiteral="false">
          <NullLiteral beginColumn="41" beginLine="11" endColumn="44" endLine="11"/>
       </Literal>
      </PrimaryPrefix>
    </PrimaryExpression>
  </EqualityExpression>
  <Expression beginColumn="48" beginLine="11" endColumn="55" endLine="11">
    <PrimaryExpression beginColumn="48" beginLine="11" endColumn="55" endLine="11">
      <PrimaryPrefix beginColumn="48" beginLine="11" endColumn="55" endLine="11">
        <Name beginColumn="48" beginLine="11" endColumn="55" endLine="11" image="UNKNWOWN"/>
      </PrimaryPrefix>
     </PrimaryExpression>
  </Expression>
  <PrimaryExpression beginColumn="59" beginLine="11" endColumn="69" endLine="11">
    <PrimaryPrefix beginColumn="59" beginLine="11" endColumn="67" endLine="11">
      <Name beginColumn="59" beginLine="11" endColumn="67" endLine="11" image="a.getTime"/>
    </PrimaryPrefix>
    <PrimarySuffix argumentCount="0" arguments="true" arrayDereference="false" beginColumn="68" beginLine="11" endColumn="69" endLine="11">
      <Arguments argumentCount="0" beginColumn="68" beginLine="11" endColumn="69" endLine="11"/>
    </PrimarySuffix>
  </PrimaryExpression>
</ConditionalExpression>

Если у вас есть сложное выражение в троичном операторе, разница в его подсчете будет еще более распространенной. Что касается того, что не так с кодом, он уже имеет 9 ветвей (8 троичных операторов и цикл), что является высоким даже без полного вычисления nPath. Я бы рефакторинг это независимо.

...