Нормально ли использовать var вместо явной типизации в C#?

Question

[Nik Faraday]

Нормально полностью отойти от явной типизации и писать всё varами? Сижу на проекте, где все коллеги так и делают, аргументируют это тем, что... Почему бы и нет? Оно ведь не ломается и всё отлично работает

Я ужасно ненавижу такой подход, потому что ты не можешь сразу определить тип, который возвращается. Как по мне, добавление возможности писать var вместо обычного типа было ужасной ошибкой Microsoft. Сам var был добавлен в язык вместе с анонимными типами и предназначался специально для них. Данный код достаточно сложно разобрать человеку, который не писал это всё с нуля, а был присоединён через 4-5 лет ведения проекта.

Comments

[Sergey В.]

Если тип переменной определён хоя бы в левой части, то всё ОК.
А вот если определение типа переменной отдано на откуп компилятору - то это не есть хорошо.
Тот же js получил разновидность ts (со строгой типизацией), чтобы не получилось ситуации что 1 + 1 = 11

[nozd up]

Данный код достаточно сложно разобрать человеку, который не писал это всё с нуля, а был присоединён через 4-5 лет ведения проекта

Документация / комментарии / информативное наименование / помощь коллег - это увеличивает скорость и комфорт погружения в проект
var'ы здесь не при чём; они только увеличивают длину строки, а полезной информации в большинстве случаев не несут

Answer 1

[Dmitry Roo]

Вполне норм. Просто тип определяется справа, а не слева.
Подсказки ide должны решить вопрос понимания человеком, что там за тип.

Comments

[Steel_Balls]

И такой код хрен разберёшь без IDE. Например, в обычном блокноте или по распечатке на бумаге.
Понятно, что так никто не делает, но мысль вы все уловили.
Программиста теперь жёстко привязывают к IDE. Без IDE он код не поймёт. И это неправильно.

[Василий Банников]

Steel_Balls,

Например, в обычном блокноте или по распечатке на бумаге.

Я бы сбежал из конторы, где нужно неиронично читать код в блокноте или по распечатке.
Если дублировать всю полезную информацию о функция в месте вызова, то так мы вернёмся к COBOL или чему-то типа того.

[Steel_Balls]

Василий Банников, ну а мне иногда приятно поностальгировать и заглянуть в мои тетради, где я 30-35 лет назад код на бумажке писал :)

[Dmitry Roo]

Steel_Balls, на бумажке можете var не использовать.

[Steel_Balls]

Dmitry Roo, СПАСИБО!!! )

Answer 2

[Василий Банников]

1. Да, это нормально. Сильно легче код писать таким образом. (а иногда и читать, тк меньше слов дублируется. Например совершенно никакой ценности не несёт User user = userRepository.GetUserById(...) или многослойный женерик)

2.

Я ужасно ненавижу такой подход, потому что ты не можешь сразу определить тип, который возвращается.

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

Ты же не задаёшься вопросом, какой тип возвращает какой-нибудь GetUser, ToString, TryParse, FirstOrDefault?

Если тебе сложно понять смысл кода без типов - значит кто-то плохие имена дал переменным.

Данный код достаточно сложно разобрать человеку, который не писал это всё с нуля, а был присоединён через 4-5 лет ведения проекта.

Очень смелое заявление, которое мало чем подкреплено.

Как по мне, добавление возможности писать var вместо обычного типа было ужасной ошибкой Microsoft. Сам var был добавлен в язык вместе с анонимными типами и предназначался специально для них.

1. var далеко не только для анонимных типов полезен, хотя с анонимными типами без var работать было бы очень сложно.

2. Тренд говорит об обратном - автоматический вывод типов сейчас есть практически во всех статически-типизированных языках в том или ином виде.

Ну и помни ещё, что ты же не в блокноте код пишешь - у тебя есть всякие inlay hints, которые могут рядом с именем переменной показать её тип, а наведя мышку на слово - ты узнаёшь о нём все (имя переменной, сигнатуру метода, документацию, итд)

Comments

[MVV]

Василий Банников , ну, что вам на это сказать?

Сильно легче код писать таким образом.

Писать - да, читать - it depends, как говорят англичане.

Если тебе сложно понять смысл кода без типов - значит кто-то плохие имена дал переменным.

А разве в legacy 4-5-летней выдержки, над которым поработало много программистов, хороших и разных, по-другому бывает? А ещё имена могут дать хорошие, понятные - но основанные на системе понятий, которая нетривиальна и не попала при этом в документацию. Чтобы понять, о чем я - попробуйте почитать исходники подсистемы маршрутизации в ASP.NET Core. лучше всего - после работы с чем-нибудь типа MVC или Razor Pages: сомневаюсь, что вы сразу въедете, что Model там и Model тут - это разные Model.

А ещё бывает, что методы называются почти одинаково, но типы значений у них разные. Пример: builder.Services.AddOptions() и builder.Services.AddOptions<TOptions>() из кода конфигурирования контейнера сервисов, методы расширения IServiceCollection для Option Patterns - типы возвращаемых значений у них разные. А их ещё любят цеплять друг к другу к таким же методам через точку - вот и смотри потом, чой-то в ConfigureOptions какие-то лишние параметры вылезли.

с анонимными типами без var работать было бы очень сложно.

Правильный вопрос - зачем вообще заставлять работать с анонимными типами? Подозреваю, что их из-за маршрутизации в MVC завезли - как типы параметров, вместо того, чтобы передавать в методы генерации ссылок вместо IDictionary<String,Object>, как это оно там реально требуется. Но, в Microsoft решили, видимо, тогда не делать инициализаторы для словарей (при том, что потом всё равно сделали, не отвертелись), а притащить вместо них анонимные типы (интересно откуда - неужели прямо из JS?). Но это не точно.

Тренд говорит об обратном - автоматический вывод типов сейчас есть практически во всех статически-типизированных языках в том или ином виде.

Это потому что сейчас главное - быстрее писать MVP, для веба - особенно. Ну, а потом можно сказать волшебное слово: "Legacy".

Ну и помни ещё, что ты же не в блокноте код пишешь

Но читаешь-то ты его не только в IDE. В частности, MS в своей документации на сайте в примерах очень любит писать var - вот и выбирай потом, что делать: лезть прямо сразу в документацию по API (а ссылки отнюдь не прилагаются) или рисковать упустить что-то важное? А если ещё учесть, что сейчас принято документацию ограничивать примерами (MS любит, да) - оно вообще весело.

Но, с другой стороны, автор вопроса, похоже, с трех- и более этажными дженериками ещё не сталкивался (ну, или забыл, как они выглядят) - там без var тоже грустно.
Как-то так

[Василий Банников]

MVV,

Правильный вопрос - зачем вообще заставлять работать с анонимными типами? Подозреваю, что их из-за маршрутизации в MVC завезли - как типы параметров, вместо того, чтобы передавать в методы генерации ссылок вместо IDictionary, как это оно там реально требуется

Анонимные типы появились задолго до нормального asp net.
Их изначально сделали ради linq.

А вот про многоэтажные женерики я и забыл

[Nik Faraday]

MVV, полностью поддерживаю ваше мнение, мне нравится ваша позиция)

Напишите, пожалуйста, отдельным ответом. Буду благодарен

[Steel_Balls]

Сильно легче код писать таким образом.

Вот в этом и проблема - ПИСАТЬ!
А автор вопроса говорит о том, что код иногда надо ЧИТАТЬ!
Какие-то там кодеры написали - и после них хоть потоп. Приходят новые разработчики и ни черта понять не могу что они там НАПИСАЛИ. Видите ли, им ПИСАТЬ было ПРОЩЕ

[Nik Faraday]

Steel_Balls, поддерживаю. Как я уже уточнял, если этот проект ведётся 4-5 лет и там всё var'ами написано. Тут без способностей экстрасенсорики не обойтись. Особенно во время дебага

UPD:
Иногда Select или ToList не даёт понимания, с чём ты работаешь. Особенно в примерах var result = service.GetAll().ToList()

[Василий Банников]

Steel_Balls,

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

Ты же не задаёшься вопросом, какой тип возвращает какой-нибудь GetUser, ToString, TryParse, FirstOrDefault?

Если тебе сложно понять смысл кода без типов - значит кто-то плохие имена дал переменным.

Есть ещё вот такая фраза, если по диагонали не читать.
Скажу так, что даже и без var можно такого говно сделать, что явные типы тебе вот никак не помогут.
(Например неиронично видел кодовую базу, где всё было через dynamic - вон там реально проще было писать, даже классы объявлять не нужно)

[Василий Банников]

Nik Faraday, var result = service.GetAll().ToList()
Вот это как раз плохой пример именования. Что за сервис? Что за GetAll? Что такое это "All"?
Не удивлюсь, если там даже с конкретным типом не особо понятно будет.

Особенно во время дебага

Так во время дебага все типы как раз и так пишутся. Что за IDE?

Answer 3

[MVV]

Вынесено из комментариев.
Василий Банников , ну, что вам на это сказать?

Сильно легче код писать таким образом.

Писать - да, читать - it depends, как говорят англичане.

Если тебе сложно понять смысл кода без типов - значит кто-то плохие имена дал переменным.

А разве в legacy 4-5-летней выдержки, над которым поработало много программистов, хороших и разных, по-другому бывает? А ещё имена могут дать хорошие, понятные - но основанные на системе понятий, которая нетривиальна и не попала при этом в документацию. Чтобы понять, о чем я - попробуйте почитать исходники подсистемы маршрутизации в ASP.NET Core. лучше всего - после работы с чем-нибудь типа MVC или Razor Pages: сомневаюсь, что вы сразу въедете, что Model там и Model тут - это разные Model.

А ещё бывает, что методы называются почти одинаково, но типы значений у них разные. Пример: builder.Services.AddOptions() и builder.Services.AddOptions<TOptions>() из кода конфигурирования контейнера сервисов, методы расширения IServiceCollection для Option Patterns - типы возвращаемых значений у них разные. А их ещё любят цеплять друг к другу к таким же методам через точку - вот и смотри потом, чой-то в ConfigureOptions какие-то лишние параметры вылезли.

с анонимными типами без var работать было бы очень сложно.

Правильный вопрос - зачем вообще заставлять работать с анонимными типами? Подозреваю, что их из-за маршрутизации в MVC завезли - как типы параметров, вместо того, чтобы передавать в методы генерации ссылок вместо IDictionary<String,Object>, как это оно там реально требуется. Но, в Microsoft решили, видимо, тогда не делать инициализаторы для словарей (при том, что потом всё равно сделали, не отвертелись), а притащить вместо них анонимные типы (интересно откуда - неужели прямо из JS?). Но это не точно. (Ага, в комментарии мне напомнили про LINQ)

Тренд говорит об обратном - автоматический вывод типов сейчас есть практически во всех статически-типизированных языках в том или ином виде.

Это потому что сейчас главное - быстрее писать MVP, для веба - особенно. Ну, а потом можно сказать волшебное слово: "Legacy".

Ну и помни ещё, что ты же не в блокноте код пишешь

Но читаешь-то ты его не только в IDE. В частности, MS в своей документации на сайте в примерах очень любит писать var - вот и выбирай потом, что делать: лезть прямо сразу в документацию по API (а ссылки отнюдь не прилагаются) или рисковать упустить что-то важное? А если ещё учесть, что сейчас принято документацию ограничивать примерами (MS любит, да) - оно вообще весело.

Но, с другой стороны, автор вопроса, похоже, с трех- и более этажными дженериками ещё не сталкивался (ну, или забыл, как они выглядят) - там без var тоже грустно.
Как-то так

Comments

[Nik Faraday]

Сталкивался, регулярно)

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

[Василий Банников]

Писать - да, читать - it depends, как говорят англичане.

Ага и вот в этом самом "зависит" var будет играть меньшую роль.
Если у тебя в коде лапша типа такой: (тут фотография серверной, где откуда-то сверху свисает огромное количество перепутанных проводов), то "бирки" с типами у каждой переменной (или проводка в случае серверной) тебе не сильно помогут в понимании.

А разве в legacy 4-5-летней выдержки, над которым поработало много программистов, хороших и разных, по-другому бывает?

1. 4-5 лет - это не так уж и много
2. Читабельность зависит не от того, сколько людей потрогало код, а от процессов и правил, которые были приняты в проекте изначально. На каждый ужасный проект, который я видел - найдётся как минимум 1 очень даже неплохой.

А ещё бывает, что методы называются почти одинаково, но типы значений у них разные. Пример: builder.Services.AddOptions() и builder.Services.AddOptions() из кода конфигурирования контейнера сервисов, методы расширения IServiceCollection для Option Patterns - типы возвращаемых значений у них разные. А их ещё любят цеплять друг к другу к таким же методам через точку - вот и смотри потом, чой-то в ConfigureOptions какие-то лишние параметры вылезли.

Это как раз пример, когда использование явных типов у переменных не поможет, тк методы вызываются по цепочке. Как раз случай, когда нужно привыкать к паттернам, читать документацию, наводить мышку на методы.

А если ещё учесть, что сейчас принято документацию ограничивать примерами (MS любит, да) - оно вообще весело.

Ой примеры - это в лучшем случае) Часто обходятся просто кратким summary. Наподобие "AddOptions - add options to service collection"

Это потому что сейчас главное - быстрее писать MVP, для веба - особенно. Ну, а потом можно сказать волшебное слово: "Legacy".

Далеко не только лишь.
Всякие ML-подобные-языки, включая F# и Haskell, Kotlin, Scala, Rust, zig, go - большинство из этих языков имеют очень опосредованное отношение к вебу и подходу "хуяк хуяк и в продакшен", но во всех них есть либо простой вывод типов по правой части выражения (как в C# и Go), так и полноценный хиндли-мильнер (F#), либо что-то среднее (Rust).

Где-то вывод типов прям необходим (из-за женериков), а где-то он просто чтобы меньше засорять код (типа го)