История изменений
Исправление witaway, (текущая версия) :
Ну то есть ты тоже за то, чтобы программист сам решал, без эффективных менеджеров и прочих корпоративных бюрократов, нужен ли ему final тут или там или нет?
Ну дык. Я же и говорю, жизнь не чёрно-белая. Смысл в этих рекомендациях есть, и, так сложилось, он есть почти всегда. Но ведь правил без исключений не бывает. Всегда надо думать головой и иметь у себя где-то в голове конкретное объяснение, почему ты сделал так, а не иначе. Вариантов, где ссылка не должна быть final миллион. Более чем с вами согласен.
Откуда эти рекомендации вообще взялись? Чтобы дураки не назначали сразу несколько семантик одной и той же переменной.
Почему появился такой карго-культ? Потому что среди менеджеров есть такие же недальновидные товарищи.
Значит ли это, что спецификаторы вроде final не нужны и только сковывают творческую свободу программиста? Ну, вообще, как правило, нет. Просто не нужно возводить в культ.
Но лично я бы, наверное, сделал как-то так, а переменную в аргументе с того момента считал изжившей своё:
public Result<...> editProfile(final User? requestedUser = null) {
User editingUser = switch(requestedUser) {
case null -> userService.getCurrentUser();
default -> requestedUser;
};
...
}
Или, если знаю, что текущий пользователь тоже будет обязательно где-то использоваться, сделаю вообще так:
public Result<...> editProfile(final User? requestedUser = null) {
User currentUser = userService.getCurrentUser();
User editingUser = switch(requestedUser) {
case null -> currentUser;
default -> requestedUser;
};
...
}
Как по мне, выглядит неплохо и всего на одну строку длиннее, чем если впилить условное изменение переменной, если она null. И, мне кажется, такая реализация более точно передаёт разницу смысловых оттенков между «запрошенным пользователем», «текущим пользователем» и «тем пользователем, которого мы будем обрабатывать».
Сделать ссылку мутируемой тоже вполне можно, но так, сугубо моё ИМХО, получится на самую каплю менее читаем. Это уже вкусовщина.
Для меня более логично сделать ссылку мутируемой если у нас, не знаю, выполняется какой-то циклический алгоритм и между итерациями нужно хранить какое-то состояние. Текущую вершину в графе, например.
Но опять же… Это ведь вопрос вкуса и здравого смысла. Всё нормально, что не совсем безобразно.
Ну вот стоило добавить const перед std::string& и у него тут же пропал append(), что и сделало такой стринг неизменным. По-моему это очень хорошая и полезная вещь и очень жаль, что в Java ничего похожего нет. Ошибка компиляции - это гораздо более сильная вещь, чем удержание в голове подробностей той или иной реализации.
Тоже, кстати, не понимаю, как так вышло. Вроде фича маст-хев, но видел её полноценно пока только в плюсах и хрусте. Может ещё где-то есть? В шарпе видел спецификатор readonly, однако, работающий только со структурами.
Исправление witaway, :
Ну то есть ты тоже за то, чтобы программист сам решал, без эффективных менеджеров и прочих корпоративных бюрократов, нужен ли ему final тут или там или нет?
Ну дык. Я же и говорю, жизнь не чёрно-белая. Смысл в этих рекомендациях есть, и, так сложилось, он есть почти всегда. Но ведь правил без исключений не бывает. Всегда надо думать головой и иметь у себя где-то в голове конкретное объяснение, почему ты сделал так, а не иначе. Вариантов, где ссылка не должна быть final миллион. Более чем с вами согласен.
Откуда эти рекомендации вообще взялись? Чтобы дураки не назначали сразу несколько семантик одной и той же переменной.
Почему появился такой карго-культ? Потому что среди менеджеров есть такие же недальновидные товарищи.
Значит ли это, что спецификаторы вроде final не нужны и только сковывают творческую свободу программиста? Ну, вообще, как правило, нет. Просто не нужно возводить в культ.
Но лично я бы, наверное, сделал как-то так, а переменную в аргументе с того момента считал изжившей своё:
public Result<...> editProfile(final User? requestedUser = null) {
User editingUser = switch(requestedUser) {
case null -> userService.getCurrentUser();
default -> requestedUser;
};
...
}
Или, если знаю, что текущий пользователь тоже будет обязательно где-то использоваться, сделаю вообще так:
public Result<...> editProfile(final User? requestedUser = null) {
User currentUser = userService.getCurrentUser();
User editingUser = switch(requestedUser) {
case null -> currentUser;
default -> requestedUser;
};
...
}
Как по мне, выглядит неплохо и всего на одну строку длиннее, чем если впилить условное изменение переменной, если она null. И, мне кажется, такая реализация более точно передаёт разницу смысловых оттенков между «запрошенным пользователем», «текущим пользователем» и «тем пользователем, которого мы будем обрабатывать». Сделать ссылку мутируемой тоже вполне можно, но так, сугубо моё ИМХО, получится на самую каплю менее читаемо.
Для меня более логично сделать ссылку мутируемой если у нас, не знаю, выполняется какой-то циклический алгоритм и между итерациями нужно хранить какое-то состояние. Текущую вершину в графе, например.
Но опять же… Это ведь вопрос вкуса и здравого смысла. Всё нормально, что не совсем безобразно.
Ну вот стоило добавить const перед std::string& и у него тут же пропал append(), что и сделало такой стринг неизменным. По-моему это очень хорошая и полезная вещь и очень жаль, что в Java ничего похожего нет. Ошибка компиляции - это гораздо более сильная вещь, чем удержание в голове подробностей той или иной реализации.
Тоже, кстати, не понимаю, как так вышло. Вроде фича маст-хев, но видел её полноценно пока только в плюсах и хрусте. Может ещё где-то есть? В шарпе видел спецификатор readonly, однако, работающий только со структурами.
Исправление witaway, :
Ну то есть ты тоже за то, чтобы программист сам решал, без эффективных менеджеров и прочих корпоративных бюрократов, нужен ли ему final тут или там или нет?
Ну дык. Я же и говорю, жизнь не чёрно-белая. Смысл в этих рекомендациях есть, и, так сложилось, он есть почти всегда. Но ведь правил без исключений не бывает. Всегда надо думать головой и иметь у себя где-то в голове конкретное объяснение, почему ты сделал так, а не иначе. Вариантов, где ссылка не должна быть final миллион. Более чем с вами согласен.
Откуда эти рекомендации вообще взялись? Чтобы дураки не назначали сразу несколько семантик одной и той же переменной.
Почему появился такой карго-культ? Потому что среди менеджеров есть такие же недальновидные товарищи.
Значит ли это, что спецификаторы вроде final не нужны и только сковывают творческую свободу программиста? Ну, вообще, как правило, нет. Просто не нужно возводить в культ.
Но лично я бы, наверное, сделал как-то так, а переменную в аргументе с того момента считал изжившей своё:
public Result<...> editProfile(final User? requestedUser) {
User editingUser = switch(requestedUser) {
case null -> userService.getCurrentUser();
default -> requestedUser;
};
...
}
Или, если знаю, что текущий пользователь тоже будет обязательно где-то использоваться, сделаю вообще так:
public Result<...> editProfile(final User? requestedUser) {
User currentUser = userService.getCurrentUser();
User editingUser = switch(requestedUser) {
case null -> currentUser;
default -> requestedUser;
};
...
}
Как по мне, выглядит неплохо и всего на одну строку длиннее, чем если впилить условное изменение переменной, если она null. И, мне кажется, такая реализация более точно передаёт разницу смысловых оттенков между «запрошенным пользователем», «текущим пользователем» и «тем пользователем, которого мы будем обрабатывать». Сделать ссылку мутируемой тоже вполне можно, но так, сугубо моё ИМХО, получится на самую каплю менее читаемо.
Для меня более логично сделать ссылку мутируемой если у нас, не знаю, выполняется какой-то циклический алгоритм и между итерациями нужно хранить какое-то состояние. Текущую вершину в графе, например.
Но опять же… Это ведь вопрос вкуса и здравого смысла. Всё нормально, что не совсем безобразно.
Ну вот стоило добавить const перед std::string& и у него тут же пропал append(), что и сделало такой стринг неизменным. По-моему это очень хорошая и полезная вещь и очень жаль, что в Java ничего похожего нет. Ошибка компиляции - это гораздо более сильная вещь, чем удержание в голове подробностей той или иной реализации.
Тоже, кстати, не понимаю, как так вышло. Вроде фича маст-хев, но видел её полноценно пока только в плюсах и хрусте. Может ещё где-то есть? В шарпе видел спецификатор readonly, однако, работающий только со структурами.
Исходная версия witaway, :
Ну то есть ты тоже за то, чтобы программист сам решал, без эффективных менеджеров и прочих корпоративных бюрократов, нужен ли ему final тут или там или нет?
Ну дык. Я же и говорю, жизнь не чёрно-белая. Смысл в этих рекомендациях есть, и, так сложилось, он есть почти всегда. Но ведь правил без исключений не бывает. Всегда надо думать головой и иметь у себя где-то в голове конкретное объяснение, почему ты сделал так, а не иначе. Вариантов, где ссылка не должна быть final миллион. Более чем с вами согласен.
Откуда эти рекомендации вообще взялись? Чтобы дураки не назначали сразу несколько семантик одной и той же переменной.
Почему появился такой карго-культ? Потому что среди менеджеров есть такие же недальновидные товарищи.
Значит ли это, что спецификаторы вроде final не нужны и только сковывают творческую свободу программиста? Ну, вообще, как правило, нет. Просто не нужно возводить в культ.
Но лично я бы, наверное, сделал как-то так, а переменную в аргументе с того момента считал изжившей своё:
public Result<...> editProfile(final User? requestedUser) {
User editingUser = switch(requestedUser) {
case null -> userService.getCurrentUser();
default -> requestedUser;
};
...
}
Или, если знаю, что текущий пользователь тоже будет обязательно где-то использоваться, сделаю вообще так:
public Result<...> editProfile(final User? requestedUser) {
User currentUser = userService.getCurrentUser();
User editingUser = switch(requestedUser) {
case null -> currentUser;
default -> requestedUser;
};
...
}
Как по мне, выглядит неплохо и всего на одну строку длиннее, чем если впилить условное изменение переменной, если она null. И, мне кажется, такая реализация более точно передаёт разницу смысловых оттенков между «запрошенным пользователем», «текущим пользователем» и «тем пользователем, которого мы будем обрабатывать». Сделать ссылку мутируемой тоже вполне можно, но так, сугубо моё ИМХО, получится на самую каплю менее читаемо.
Для меня более логично сделать ссылку мутируемой если у нас, не знаю, выполняется какой-то циклический алгоритм и между итерациями нужно хранить какое-то состояние. Текущую вершину в графе, например.
Но опять же… Это ведь вопрос вкуса и здравого смысла. Всё нормально, что не совсем безобразно.