В чем причина этих правил PMD?

Ответ 1

• Аномалии DD и DU (если я правильно помню, я использую FindBugs, и сообщения немного отличаются) ссылаются на присвоение значения локальной переменной, которая никогда не читается, обычно потому, что она переназначает другое значение раньше читается. Типичным случаем будет инициализация некоторой переменной с null при ее объявлении. Не объявляйте переменную, пока она не понадобится.

• Присвоение null локальной переменной, чтобы "помочь" сборщику мусора - миф. PMD позволяет вам знать, что это просто контрпродуктивный беспорядок.

• Задание final на локальной переменной должно быть очень полезно для оптимизатора, но у меня нет конкретных примеров текущих JIT, которые используют этот намек. Я нашел это полезным в рассуждении о правильности моего собственного кода.

• Указание интерфейсов в терминах & hellip; ну, интерфейсы - отличная дизайнерская практика. Вы можете легко изменять реализации коллекции, не влияя на вызывающего. Что все интерфейсы.

• Я не могу придумать много случаев, когда вызывающему абоненту потребуется LinkedList, поскольку он не предоставляет API, который не объявлен каким-либо интерфейсом. Если клиент полагается на этот API, он доступен через правильный интерфейс.

• Синхронизация уровня блока позволяет критическому разделу быть меньшим, что позволяет выполнять как можно большую работу одновременно. Возможно, что более важно, это позволяет использовать объект блокировки, который контролируется конфиденциальным объектом. Таким образом, вы можете гарантировать отсутствие взаимоблокировки. Используя сам экземпляр в качестве блокировки, любой может некорректно синхронизировать его, вызывая тупик.

• Операнды типа short передаются на int в любых операциях. Это правило позволяет вам знать, что это продвижение происходит, и вы также можете использовать int. Однако использование типа short может сохранить память, поэтому, если это член экземпляра, я бы, вероятно, проигнорировал это правило.

Ответ 2

DataflowAnomalyAnalysis: Найдено 'DD'-аномалия для переменной' variable ' (строки 'n1' - 'n2').

DataflowAnomalyAnalysis: Найдено 'DU'-аномалия для переменной' variable ' (строки 'n1' - 'n2').

Не знаю.

NullAssignment: присвоение объекта объекту null - это запах кода. Рассматривать рефакторинга.

Не задает ли объект null помощь в сборке мусора, если объект является локальным объектом (не используется вне метода)? Или это миф?

Объекты в локальных методах помечены как мусор, собранный после возвращения метода. Установка их в значение null не будет иметь никакого значения.

Поскольку это создало бы меньше опыта разработчиков, то что это нулевое присваивание, все это можно считать запахом кода.

MethodArgumentCouldBeFinal: параметр "param" не назначается и может быть объявленный окончательный

LocalVariableCouldBeFinal: локальный переменная 'variable' может быть объявлена Окончательный

Есть ли какие-либо преимущества в использовании параметров и переменных 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 помогает предотвратить такие вещи.

LooseCoupling: избегать использования типы реализации, такие как 'LinkedList'; использовать интерфейс вместо

Если я знаю, что мне определенно нужен LinkedList, почему бы мне не использовать его, чтобы мои намерения явно были ясны будущим разработчикам? Это одна вещь, чтобы вернуть класс, который находится выше класса, который имеет смысл, но почему бы мне не объявить мои переменные в строгом смысле?

В этом случае нет никакой разницы. Я думаю, что, поскольку вы не используете специальную функциональность LinkedList, предложение справедливо.

Сегодня LinkedList может иметь смысл, но, используя интерфейс, вы помогаете себе (или другим) легко менять его, когда это не будет.

Для небольших личных проектов это может и не иметь смысла, но поскольку вы уже используете анализатор, я думаю, вы уже заботитесь о качестве кода.

Кроме того, помогает менее опытному разработчику создавать хорошие привычки. [Я не говорю, что вы один, но анализатор вас не знает;)]

AvoidSynchronizedAtMethodLevel: используйте уровень блока, а не уровень метода синхронизация

Какие преимущества имеет синхронизация на уровне блоков по сравнению с синхронизацией на уровне метода?

Чем меньше синхронизированный раздел, тем лучше. Что это.

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

AvoidUsingShortType: не использовать короткий тип

Мои первые языки были C и С++, но в мире Java, почему я не должен использовать тип, который лучше всего описывает мои данные?

Я никогда не слышал об этом, и я согласен с тобой:) Я никогда не использовал короткий, хотя.

Мое предположение заключается в том, что, не используя его, вы сами сможете обновить до int.

Запахи кода более ориентированы на качество кода, чем оптимизация производительности. Поэтому советы даются для менее опытных программистов и во избежание ошибок, чем для улучшения скорости программы.

Таким образом, вы можете сэкономить много времени и разочарований при попытке изменить код, чтобы он соответствовал лучшему дизайну.

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

Ответ 3

Просто заметьте вопрос final.

Полагая "final" на переменную, результат в ней может быть назначен только один раз. Это не обязательно означает, что его легче написать, но это, безусловно, означает, что его легче читать для будущего сопровождающего.

Пожалуйста, рассмотрите следующие моменты:

• любая переменная с final может быть немедленно классифицирована в "не изменит значение во время просмотра".
• подразумевается, что если все переменные, которые не будут меняться, будут помечены как final, тогда переменные NOT, помеченные окончательным, действительно будут изменены.

Это означает, что вы уже видите, когда читаете часть определения, какие переменные нужно искать, поскольку они могут изменять значение во время кода, а сопровождающий может лучше потратить свои усилия, поскольку код более читабельен.

Ответ 4

Не установил бы объект null помощь в сборе мусора, если объект является локальным объектом (не используется вне метода)? Или это то, что миф?

Единственное, что он делает, это сделать возможным, чтобы объект был GCd до конца метода, что редко бывает когда-либо необходимым.

Есть ли какие-либо преимущества в использовании конечных параметров и переменных?

Это делает код несколько яснее, так как вам не нужно беспокоиться о том, что значение изменяется при анализе кода. Чаще всего вам не нужно или хотите изменить значение переменной после его установки.

Если я знаю, что мне особенно нужна LinkedList, почему бы мне не использовать его для сделать мои намерения ясными будущих разработчиков?

Можете ли вы подумать о какой-либо причине, по которой вам LinkedList?

Это одна вещь для верните класс, который путь, который имеет смысл, но почему я бы не объявил мои переменные в строжайшем смысле?

Мне не все равно, что касается локальных переменных или полей, но если вы объявите параметр метода типа LinkedList, я буду охотиться на вас и причинить вам вред, потому что это делает невозможным использование таких вещей, как Arrays.asList() и Collections.emptyList().

Какие преимущества имеет синхронизация на уровне блоков по сравнению с синхронизацией на уровне метода?

Самый большой из них - это то, что он позволяет использовать выделенный объект монитора, чтобы только эти критические разделы были взаимоисключающими, а не все, используя один и тот же монитор.

в мире Java, почему я не должен используйте тип, который лучше всего описывает мои данные?

Поскольку типы, меньшие, чем int, автоматически повышаются до int для всех вычислений, и вам нужно отказаться, чтобы присвоить им что-либо. Это приводит к загроможденному коду и довольно большому количеству споров (особенно при использовании автобоксинга).

Ответ 5

AvoidUsingShortType: не используйте короткий тип

• Элемент списка

  short - 16 бит, 2 комплимента в java

• короткая математическая операция с чем-либо в семействе Integer за пределами другого короткого текста потребует преобразования расширений знака времени выполнения в больший размер. для работы с плавающей точкой требуется расширение знака и нетривиальное преобразование в IEEE-754.
• не может найти доказательство, но с 32-битным или 64-разрядным регистром вы больше не сохраняете "инструкции процессора" на уровне байт-кода. Вы паркуете компактный автомобиль в месте для парковки полуприцепа до регистра процессора.
• Если вы оптимизируете свой проект на уровне байтового кода, ничего себе. Просто вау.; P
• Я согласен на стороне дизайна, игнорируя это предупреждение pmd, просто взвешивайте точное описание вашего объекта с "короткими" по сравнению с полученными преобразованиями производительности.
• По моему мнению, полученные результаты производительности незначительны для большинства машин. игнорировать ошибку.

Ответ 6

Какие преимущества имеет блок-уровень синхронизация осуществляется по методу Синхронизация? Синхронизация метода похожа на блок synchronize(getClass()) и блокирует весь класс.

Возможно, вы не хотите, чтобы