LINUX.ORG.RU

История изменений

Исправление 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. Ну вот нахрена?