История изменений
Исправление zg, (текущая версия) :
Смысл строгих языков программирования в том, чтобы позволять выражать программисту некоторые ограничения.
Ограничения в полях класса понятны и речь не о них. Но зачем самого себя ограничивать внутри функции в отношении локальных переменных?
В подавляющем большинстве исходников 99% переменных не изменяют своего значения.
Это, мягко говоря, не так.
И это привносит смысл в то, чтобы специальным образом обозначать все остальные переменные. Если ты видишь
val user = userService.getCurrentUser()
ты в уме запоминаешь, что в переменной user лежит текущий юзер и это не изменится никогда.
Не вижу в этом никакого практического смысла. Если мы говорим о коде какого-то метода или функции и если это не говнокод на несколько сотен строк, то мне и так прекрасно видно что лежит в переменной user
и изменяю ли я её после той строки или нет. В аргументах метода/функции, когда меня заставляют объявлять их final
, всё ещё хуже. Какой-то корпоративный бюрократ решает за меня как мне пользоваться моими же переменными в написанном мной коде. Иногда эти переменные таки надо изменять и приходится создавать новые. В итоге у меня может быть user
из аргументов и ещё какой-то второй локальный user2
, допустим инициализируемый именно так, как в твоём примере, если в user
из аргументов пришёл null
и он final
. Ну вот нахрена?
Исправление zg, :
Смысл строгих языков программирования в том, чтобы позволять выражать программисту некоторые ограничения.
Ограничения в полях класса понятны и речь не о них. Но зачем самого себя ограничивать внутри функции в отношении локальных переменных?
В подавляющем большинстве исходников 99% переменных не изменяют своего значения.
Это, мягко говоря, не так.
И это привносит смысл в то, чтобы специальным образом обозначать все остальные переменные. Если ты видишь
val user = userService.getCurrentUser()
ты в уме запоминаешь, что в переменной user лежит текущий юзер и это не изменится никогда.
Не вижу в этом никакого практического смысла. Если мы говорим о коде какого-то метода или функции и если это не говнокод на несколько сотен строк, то мне и так прекрасно видно что лежит в переменной user
и изменяю ли я её после той строки или нет. В аргументах метода/функции, когда меня заставляют объявлять их final
, всё ещё хуже. Какой-то корпоративный бюрократ решает за меня как мне пользоваться моими же переменными в написанном мной коде. Иногда эти переменный таки надо изменять и приходится создавать новые. В итоге у меня может быть user
из аргументов и ещё какой-то второй локальный user2
, допустим инициализируемый именно так, как в твоём примере, если в user
из аргументов пришёл null
и он final
. Ну вот нахрена?
Исходная версия zg, :
Смысл строгих языков программирования в том, чтобы позволять выражать программисту некоторые ограничения.
Ограничения в полях класса понятны и речь не о них. Но зачем самого себя ограничивать внутри функции в отношении локальных переменных?
В подавляющем большинстве исходников 99% переменных не изменяют своего значения.
Это, мягко говоря, не так.
И это привносит смысл в то, чтобы специальным образом обозначать все остальные переменные. Если ты видишь
val user = userService.getCurrentUser()
ты в уме запоминаешь, что в переменной user лежит текущий юзер и это не изменится никогда.
Не вижу в этом никакого практического смысла. Если мы говорим о коде какого-то метода или функции и если это не говнокод на несколько сотен строк, то мне и так прекрасно видно что лежит в переменной user
и изменяю ли я её после той строки или нет. В аргументах метода/функции, когда меня заставляю объявлять их final
, всё ещё хуже. Какой-то корпоративный бюрократ решает за меня как мне пользоваться моими же переменными в написанном мной коде. Иногда эти переменный таки надо изменять и приходится создавать новые. В итоге у меня может быть user
из аргументов и ещё какой-то второй локальный user2
, допустим инициализируемый именно так, как в твоём примере, если в user
из аргументов пришёл null
и он final
. Ну вот нахрена?