Зачем отмечать локальные переменные и параметры метода как окончательные в Java?

Вы должны попытаться сделать это, когда это уместно. Помимо того, что он предупреждает вас, когда вы «случайно» пытаетесь изменить значение, он предоставляет компилятору информацию, которая может привести к лучшей оптимизации файла класса. Это один из моментов в книге Роберта Симмонса-младшего "Hardcore Java". Фактически, вся вторая глава книги посвящена использованию final для содействия оптимизации и предотвращения логических ошибок. По этой причине инструменты статического анализа, такие как PMD и встроенная SA Eclipse, помечают такие случаи.

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

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

Но, конечно, это все личные предпочтения ;-)

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

Следовательно, not использование final делает ваш код менее читабельным и удобным для сопровождения, само по себе :)

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

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

В случае с магическими числами я бы все равно поместил их как постоянное частное поле, а не в код.

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

Я определенно согласен с доработкой параметра var.

Доработка локальных var кажется несколько излишней IMO.

Да, сделай это.

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

Достойной альтернативой является включение предупреждения IDE при назначении параметра или когда переменная (кроме переменной цикла) назначается более одного раза.

final имеет три веские причины:

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

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

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

Создание локальных переменных и параметров метода final важно, если вы хотите передать эти параметры анонимным классам - например, вы создаете экземпляр анонимного потока и хотите получить доступ к этим параметрам в теле метода run ().

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

Было бы неплохо узнать любую статистику производительности при использовании final ...

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

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

Изменить

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

Я позволяю Eclipse делать это за меня, когда они используются в анонимном классе, и этот показатель увеличивается из-за использования мной Google Collection API.

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

Параметры не являются окончательными, поскольку у нас есть Checkstyle-Check, который проверяет переназначение параметров. Конечно, никто никогда не захочет переназначать переменную параметра.