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

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

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

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

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

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

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

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

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 и C ++, но почему в мире Java мне не следует использовать тип, который лучше всего описывает мои данные?

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

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

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

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

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

Замечание по final вопросу.

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

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

• любую переменную с final можно сразу отнести к категории «не изменяет значение при просмотре».
• косвенно это означает, что если все переменные, которые не будут меняться, помечены как final, то переменные, НЕ помеченные как final, на самом деле БУДУТ изменяться.

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

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

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

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

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

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

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

Одно дело - вернуть класс, который находится наверху пути к классам, который имеет смысл, но почему бы мне не объявить свои переменные самыми строгими?

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

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

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

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

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

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

• Пункт списка

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

• короткая математическая операция с чем-либо в семействе Integer, кроме другого короткого, потребует преобразования расширения знака времени выполнения в больший размер. работа с плавающей точкой требует расширения знака и нетривиального преобразования в IEEE-754.

• не могу найти доказательств, но с 32-битным или 64-битным регистром вы больше не экономите на «инструкциях процессора» на уровне байт-кода. Вы паркуете малолитражку на стоянке полуприцепа, что касается регистра процессора.

• Если вы оптимизируете свой проект на уровне байтового кода, ничего себе. Просто вау. ;П

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

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

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

Может ты этого не хочешь