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

StackOverflow https://stackoverflow.com/questions/1615419

  •  06-07-2019
  •  | 
  •  

Вопрос

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

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

DD и DU звучат знакомо...Я хочу сказать о таких вещах, как тестирование и анализ, касающихся самых слабых условий до и после, но я не помню подробностей.

Нулевое назначение:Присвоение объекту значения null - это запах кода.Рассмотрим рефакторинг.

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

Метод аргументации может быть окончательным:Параметр 'param' не назначен и может быть объявлен окончательным

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

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

Ослабленное соединение:Избегайте использования типов реализации, таких как 'LinkedList';используйте интерфейс вместо этого

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

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

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

Избегайте использования Shorttype:Не используйте тип short

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

Это было полезно?

Решение

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

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

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

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

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

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

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

Другие советы

  

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 вызывается, если условия не выполнены (согласно вашим выводам)

Вам потребуется некоторое время, чтобы выяснить, что в какой-то момент в середине somone меняет ссылку и что вы используете другой объект.

Использование final помогает предотвратить подобные вещи.

  

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

     

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

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

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

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

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

  

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

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

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

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

  

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

     

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

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

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

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

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

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

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

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

  

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

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

  

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

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

  

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

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

  

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

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

  

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

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

  

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

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

Избегайте использования Shorttype:Не используйте короткий тип

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

    short - это 16 бит, дополнение 2 в java

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

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

Может быть, вы этого не хотите

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top