DataflowAnomalyAnalysis: Found
'DD' -аномалия для переменной 'variable'
(строки 'n1' - 'n2').
DataflowAnomalyAnalysis: Found
'DU' -аномалия для переменной 'variable'
(строки 'n1' - 'n2').
Не знаю.
NullAssignment: назначение объекта
ноль - это запах кода. Рассматривать
рефакторинга.
Не поможет ли установка объекта на null помочь в сборке мусора, если объект является локальным объектом (не используется вне метода)? Или это миф?
Объекты в локальных методах помечаются как сборщики мусора после возврата метода. Установка их в ноль не будет иметь никакого значения.
Поскольку разработчикам было бы меньше опыта, то что это за нулевое назначение, можно считать запахом кода.
MethodArgumentCouldBeFinal: Параметр
'param' не назначен и может быть
объявлен окончательным
LocalVariableCouldBeFinal: Local
переменная переменная может быть объявлена
Окончательный
Есть ли какие-либо преимущества в использовании final параметров и переменных?
Понятно, что значение не изменится в течение жизненного цикла объекта.
Кроме того, если кто-то случайно попытается присвоить значение, компилятор предотвратит эту ошибку кодирования при типе компиляции.
рассмотрим это:
public void businessRule( SomeImportantArgument important ) {
if( important.xyz() ){
doXyz();
}
// some fuzzy logic here
important = new NotSoImportant();
// add for/if's/while etc
if( important.abc() ){ // <-- bug
burnTheHouse();
}
}
Предположим, вам поручено решить какую-то загадочную ошибку, которая время от времени сжигает дом.
Вы знаете, что это за параметр, который вы не понимаете: ПОЧЕМУ метод burnTHeHouse вызывается, если условия не выполняются (согласно вашим выводам)
Вам понадобится некоторое время, чтобы выяснить, что в какой-то момент посередине сомон меняет ссылку, и вы используете другой объект.
Использование final помогает предотвратить подобные вещи.
Свободная связь: избегать использования
типы реализации, такие как
'LinkedList'; использовать интерфейс
вместо
Если я знаю, что мне конкретно нужен LinkedList, почему бы мне не использовать его, чтобы четко обозначить свои намерения для будущих разработчиков? Одно дело возвращать класс, который является наивысшим по сравнению с путем к классу, что имеет смысл, но почему бы мне не объявить, что мои переменные имеют самый строгий смысл?
В этом случае разницы нет. Я думаю, что, поскольку вы не используете LinkedList специальные функции, предложение справедливо.
Сегодня LinkedList может иметь смысл, но с помощью интерфейса вы помогаете себе (или другим) легко изменить его, когда это не нужно.
Для небольших личных проектов это может вообще не иметь смысла, но, поскольку вы уже используете анализатор, я думаю, вы уже заботитесь о качестве кода.
Также, помогает менее опытному разработчику создавать хорошие привычки. [Я не говорю, что вы один, но анализатор не знает вас;)]
AvoidSynchronizedAtMethodLevel: использовать
уровень блока, а не уровень метода
синхронизация
Какие преимущества имеет синхронизация на уровне блоков по сравнению с синхронизацией на уровне методов?
Чем меньше синхронизированный раздел, тем лучше. Вот и все.
Кроме того, если вы синхронизируете на уровне метода, вы заблокируете весь объект. Когда вы синхронизируете на уровне блоков, вы просто синхронизируете этот конкретный раздел, в некоторых ситуациях это то, что вам нужно.
AvoidUsingShortType: не используйте
короткий тип
Моими первыми языками были C и C ++, но в мире Java, почему я не должен использовать тип, который лучше всего описывает мои данные?
Я никогда не слышал об этом, и я согласен с вами :) Хотя я никогда не использую шорт.
Я предполагаю, что, не используя его, вы поможете себе перейти на int без проблем.
Запахи кода больше ориентированы на качество кода, чем на оптимизацию производительности. Таким образом, совет дан для менее опытных программистов и избежать подводных камней, чем улучшить скорость программы.
Таким образом, вы можете сэкономить много времени и разочарований при попытке изменить код, чтобы он соответствовал лучшему дизайну.
Если совет не имеет смысла, просто проигнорируйте их, помните, что вы разработчик, а инструмент - это просто инструмент. Если что-то пойдет не так, вы не можете винить инструмент, верно?