DataflowAnomalyAnalysis: Найдено 'DD'-аномалия для переменной 'переменная' (строки 'n1' -' п2').
DataflowAnomalyAnalysis: Найдено 'DU'-аномалия для переменной' variable ' (lines' n1 '-' n2 ').
Не знаю.
NullAssignment: присвоение объекта null - код запаха. Рассмотрим рефакторинг.
Не задал ли объект null
помощь в сборке мусора, если объект является локальным объектом (не используется вне метода)? Или это миф?
Объекты в локальных методах помечены как мусор, собранный после возвращения метода. Установка их в значение null не будет иметь никакого значения.
Поскольку это создало бы меньше опыта разработчиков, то что это нулевое присваивание, все это может считаться запахом кода.
MethodArgumentCouldBeFinal: Параметр «пары» не назначаются и может быть объявила окончательный
LocalVariableCouldBeFinal: Локальная переменный «переменная» может быть объявлена окончательного
Существует ли какое-либо преимущество использования 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
вызывается, если условия не будут выполнены (в соответствии с вашими выводами)
Это может занять некоторое время, чтобы узнайте, что в какой-то момент посередине somone измените ссылку, и что вы используете другие объект.
Использование final
помогает предотвратить подобные вещи.
LooseCoupling: Избегайте использования типов реализации как 'LinkedList'; использовать интерфейс вместо
Если я знаю, что конкретно нужен LinkedList
, почему бы не использовать один, чтобы сделать мои намерения явно ясно будущих разработчиков? Одно дело - вернуть класс, который является самым высоким по пути класса, который имеет смысл, но почему бы мне не объявить, что мои переменные имеют самый строгий смысл?
В этом случае нет никакой разницы. Я бы подумал, что, поскольку вы не используете LinkedList
конкретную функциональность, предложение справедливо.
Сегодня LinkedList может иметь смысл, но с помощью интерфейса вы помогаете себе (или другим) легко менять его, когда это не будет.
Для небольших личных проектов это может не иметь никакого смысла, но поскольку вы уже используете анализатор, я думаю, вы уже заботитесь о качестве кода.
Также помогает менее опытному разработчику создавать хорошие привычки. [Я не говорю, что ты один, но анализатор не знает вас;)]
AvoidSynchronizedAtMethodLevel: Используйте на уровне блоков, а не уровня метода синхронизации
Какие преимущества синхронизации на уровне блоков имеют более сложную синхронизацию?
Чем меньше синхронизированный участок, тем лучше. Вот и все.
Также, если вы синхронизируете на уровне метода, вы заблокируете весь объект. Когда вы синхронизируете на уровне блока, вы просто синхронизируете этот конкретный раздел, в некоторых ситуациях это то, что вам нужно.
AvoidUsingShortType: Не используйте короткий тип
Мои первые языки C и C++, но и в мире Java, почему я не должен использовать тот тип, который лучше всего описывает мои данные?
Я никогда не слышал об этом, и я согласен с тобой :) Я никогда не использовал короткое, хотя.
Мое предположение заключается в том, что, не используя его, вы будете помогать себе обновляться до int
без проблем.
Запахи кода более ориентированы на качество кода, чем оптимизация производительности. Поэтому советы даются для менее опытных программистов и во избежание ошибок, чем для улучшения скорости программы.
Таким образом, вы можете сэкономить много времени и разочарований при попытке изменить код, чтобы он соответствовал лучшему дизайну.
Если это совет не имеет смысла, просто игнорируйте их, помните, что вы являетесь разработчиком при зарядке, а инструмент - это только инструмент. Если что-то пойдет не так, вы не можете обвинять инструмент, верно?
Операнды типа byte также передаются в int в любых операциях. –
Итак, это операнды типа 'char', но это также не относится к этому вопросу. – erickson