Здравствуйте, vsb, Вы писали:

vsb>Optional<Person> я бы назвал personOpt.

фишка rust здесь весьма кстати:

let person = personRepository.get(personId);
if let Some(person) = person {
    ...
}

кстати, интересно, в других языках что мешает переопределить имя под другой тип? Н-р:

Year parseYear(std::string_view year){
    auto year = parse<int>(year);
    return Year{ year };
}

Здравствуйте, vsb, Вы писали:

vsb>Ну в первой будет int. Ладно, за С++ говорить не буду, там в этих целочисленных типах чёрт ногу сломит, в жаве в этом плане всё проще. В третьем будет тип Person.
И зачем гадать, когда как написать "int" было ничуть не сложнее, а "Person" немногим сложнее, а выглядело бы гораздо аккуратнее и просто опрятнее.

Здравствуйте, ·, Вы писали:

·>В общем случае конечно фигня. А в таком случае какие вопросы?
·>

·>auto user = getUser();
·>auto account = getAccount();
·>remove(user);
·>remove(account);
·>

Тогда обсуждение теряет смысл

remove(getUser());
remove(getAccount());

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

Здравствуйте, Skorodum, Вы писали:

S>

S>AccountType accountType = getAccountType();
S>

S>А так знаете? По-моему, с auto тут лучше.

Вариант с AccountType удобнее — если надо найти этот тип и понять, что этот тип из себя представляет и что с ним можно делать.

S>Думаю, что дело не столько в знании проекта, сколько в нормальном наименовании функций и переменных. Не агитирую за повсеметсное auto, но очень часто оно уместно.

Наименование нормальное, конечно же, никто не отменял, но разобраться будет быстрее, легче и проще —
если вместо auto есть конкретный тип.

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

Здравствуйте, Shmj, Вы писали:

S>Если не указывать тип везде, где только возможно — использовать auto. Какие минусы?

Помимо уже много раз упомянутой читаемости, также падает redundancy. Что в большинстве случаев не проблема, а даже плюс, особенно в generic коде.
Но в некоторых случаях нужно именно ограничение допустимого типа (или набора совместимых типов), чтобы повысить надёжность (убрав duck-typing) в свете возможных изменений upstream компонентов.

Здравствуйте, sergii.p, Вы писали:

SP>кстати, интересно, в других языках что мешает переопределить имя под другой тип? Н-р:

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

Здравствуйте, pagid_, Вы писали:

_>Ну не знаю. По мне так var безусловно уместен только во второй строчке.

Почему не в 1-й?

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Но только мы по-прежнему не знаем, что можно сделать с этим accountType — ни какие данные из него получить, ни какому методу его можно скормить.
SVZ>Это хорошо тому, кто с этой частью проекта хорошо знаком и представляет, что возвращает getAccountType.

Так где-то рядом этот тип как-то используется, по контексту будет ясно. Сам по себе он не интересен.

SVZ>Ну и потенциальные ошибки — например, видя тип можно сразу среагировать на передачу по значению, вместо ссылки.
SVZ>А тут пёс его знает. То ли accountType это енум, то ли интерфейс, то ли разлапистая структура
SVZ>Без IDE шагу не ступить.

А что ты с этим типом делать собрался? Я думал, речь о чтении кода, а если пишешь, то ты и так знаешь, зачем ты этот тип запрашивал, и что с ним собираешься делать.

Здравствуйте, ути-пути, Вы писали:

SVZ>>А тут пёс его знает. То ли accountType это енум, то ли интерфейс, то ли разлапистая структура
SVZ>>Без IDE шагу не ступить.

УП>А что ты с этим типом делать собрался? Я думал, речь о чтении кода, а если пишешь, то ты и так знаешь, зачем ты этот тип запрашивал, и что с ним собираешься делать.

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

Здравствуйте, ути-пути, Вы писали:

УП>Почему не в 1-й?
В первой int ничем не хуже. Зачем его прятать?