Является ли хорошей практикой объявлять переменные "final", где это возможно?

Возможный дубликат:
Когда следует использовать окончательный вариант?

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

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

Ответ 1

"Java-путь" по своей сути, по сути, беспорядок.

Я говорю, что это хорошая практика, но я не следую за ней.

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

Я категорически не согласен с тем, что он создает "беспорядок кода"; это хороший и мощный аспект языка.

В качестве принципа разработки вы должны сделать свои классы immutable (все конечные поля), если сможете, потому что они могут быть безопасно опубликованы (то есть свободно проходили без страха, они будут испорчены). Хотя обратите внимание, что сами поля также должны быть неизменяемыми объектами.

Ответ 5

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

Он также сообщает компилятору, что он не изменится, что может привести к лучшей оптимизации.

Вдоль стороны это позволяет вашей среде IDE дать вам уведомление о времени компиляции, если вы склонны делать какие-либо ошибки.

Ответ 6

Некоторые хорошие инструменты анализа, такие как PMD, советуют ставить всегда final, если это необходимо. Таким образом, соглашение в этих инструментах говорит о хорошей практике.

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

Ответ 7

Вы в значительной степени суммировали плюсы и минусы...

Я могу добавить еще один символ con:

читателю кода не нужно вообще не рассуждать о значении конечной переменной (за исключением редких случаев с плохим кодом).

Итак, да, это хорошая практика.

И беспорядок не так уж плох, после того как вы привыкнете к нему (например, unix: -P). Кроме того, типичные IDE делают это автоматически для ya...

Ответ 8

Я бы сказал, да, не столько для оптимизации компилятора, сколько для читаемости.

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