Я предпочитаю этот стиль письма с ранней отдачей:
public static Type classify(int a, int b, int c) {
if (!isTriangle(a, b, c)) {
return Type.INVALID;
}
if (a == b && b == c) {
return Type.EQUILATERAL;
}
if (b == c || a == b || c == a) {
return Type.ISOSCELES;
}
return Type.SCALENE;
}
К сожалению, каждый оператор return увеличивает показатель цикломатической сложности, вычисляемый Sonar. Рассмотрим эту альтернативу:
public static Type classify(int a, int b, int c) {
final Type result;
if (!isTriangle(a, b, c)) {
result = Type.INVALID;
} else if (a == b && b == c) {
result = Type.EQUILATERAL;
} else if (b == c || a == b || c == a) {
result = Type.ISOSCELES;
} else {
result = Type.SCALENE;
}
return result;
}
Цикломатическая сложность этого последнего подхода, о котором сообщает Sonar, ниже, чем у первого, на 3. Мне сказали, что это может быть результатом неправильной реализации метрик CC. Или Сонар прав, и это действительно лучше? Эти связанные вопросы, кажется, не согласны с этим:
Если я добавлю поддержку еще нескольких типов треугольников, операторы return в сумме существенно изменят метрику и вызовут нарушение Sonar. Я не хочу ставить этому методу // NOSONAR, так как это может замаскировать другие проблемы новыми функциями/ошибками, добавленными к методу в будущем. Поэтому я использую вторую версию, хотя она мне не очень нравится. Есть ли лучший способ справиться с ситуацией?
return. Это правилоsquid:MethodCyclomaticComplexity: dev.eclipse.org/sonar/rules/show/ Более раннее правило (но теперь устаревшее в пользу squid) не имело этого ограничения: dev.eclipse.org/sonar/rules/show/ - person janos schedule 15.09.2014