Вы затронули очень холиварную тему, приведу аргументы почему использовать var по дефолту это нормальная практика. 1. Использование явного типа может увеличивать когнитивную нагрузку пишущего, поскольку он может не помнить точного название типа, возвращаемого методом, и также вынужден наводиться и проваливаться, чтобы этот тип написать. Это видно даже в Вашем видео, где Вы засомневались в типах и стали проваливаться в их объявления) 2. Когнитивная нагрузка читающего может снижаться, но часто это ничего не дает. Если тип стандартный или читающий с ним хорошо знаком, то его очень легко вывести по контексту. Если же вы не знаете тип, то аннотация разве что поможет Вам провалиться в тип в один клик вместо двух, либо, если повезет, что-то понять из названия типа. 3. Часто читающему и не нужно знать, что за тип используется в данном конкретном месте, потому что по названию переменной в совокупности с названиями используемых методов и так понятно, что данный участок кода делает, если все хорошо названо. В таком случаем тип становится просто визуальным шумом, который только мешает. 4. Подсвечивания типов IDE без их явного прописывания, как Вам уже написали в комментариях, очень хорошая вещь, т.к. она одновременно может снизить нагрузку пишущего, поскольку он может использовать var и снизить нагрузку с читающего, поскольку он видит тип. 5. Автоматический вывод типов - это тенденция в современном программировании. Он появился во многих старых языках (С#, C++, Java), и я не знаю ни одного нового языка, в котором бы его не было, например, он есть в Dart, Kotlin, Rust. Причем в новых языках он рассматривается, как дефолтный вариант, и прописывание типов оставлено для ситуаций, когда вывод не справляется или справляется плохо. Вы показали такие ситуации в видео, однако в большинстве случаев вывод типов справляется достаточно хорошо. 6. Куча языков с динамической типизацией нормально себя чувствовали вообще без аннотаций типов. А после того, как они в них появились (Python, TypeScript) стандартной практикой стало считаться использовать их только в сигнатурах и опять же в спорных ситуациях, где вывод не справляется. В остальных ситуациях используется аналог var из Java. Вы, конечно, можете ограничить или запретить использовать var в своей кодовой базе, и это будет нормально, но это вопрос стиля, аргументы есть в обе стороны. Поэтому мне кажется странным объявлять практику, которая нравится огромному количеству людей, ошибочной. Мне кажется, что неприятие этой фичи во многом исходит из консерватизма Java программистов. В C#, например, эта фича появилась в 2007 году и всем уже давно ок, а в Java var ввели в 2018 и код написанный на var, может выглядеть, как нарушение всех возможных основ)))
Млин ну серьезно, откуда вы такие беретесь. >> Использование явного типа может увеличивать когнитивную нагрузку пишущего, поскольку он может не помнить точного название типа, Код пишется один раз - читается тыщу. Лучше "когнитивно нагрузиться" один раз в процесске писки чем потом постоянно держать тип в башке и гадать "что эта хрень делает". Рефакторинг "выделение переменной" горячими кнопками очень быстро помогает обьявить тип возвращаемый правой частью. Вся нагрузка пропадает. >>Если тип стандартный или читающий с ним хорошо знаком, то его очень легко вывести по контексту. Ну нах..я? Если его просто можно тыпо написать и ничего не вывыдить, фокусируясь но бОльшей задаче. >>Часто читающему и не нужно знать, что за тип используется в данном конкретном месте, потому что по названию переменной в совокупности с названиями используемых методов и так понятно,... Чаще нужно, чтобы понимать что происходит и ведеть большую картинку... Все аргументы справедливы для программок типа Хелло Ворлд.
"Использование явного типа может увеличивать когнитивную нагрузку пишущего, поскольку он может не помнить точного название типа, " как указание типа увеличивает когнитивную нагрузку? мол если не видишь ничего то и думать не надо?
Спасибо, интересное видео. Я - за var :) Var снижает многословность Java, за которую многие ее ругают. Ну и зачем писать два раза тип переменной - слева и справа?
Переходи на котлин, зачем страдать на джаве? Объявление типа переменной было нужно, чтобы упростить компилятор, так как машины тех лет были несказанно слабее нынешних. Вместо финал вар, нужно было сделать лет или конст - это да, промах. Посмотри на те же котлин, с шарп, тайпскрипт - всё ок, проблем с типами не. Если у тебя есть 2 метода, которые принимают Лист и Итерэйбл, а у тебя переменная АррвйЛист, то тебе нужно кастовать. Большинство примеров высосаны из пальца и на практике ошибки сразу дадут о себе знать, и вообще так никто не напишет.
@@kotojava Упростить компилятор? - да, представь себе, лет 20 назад 512 мб оперативики - это был шик, процессоры в то время были на несколько порядков медленнее. А чтобы сделать вывод типа - нужно заглянуть дальше в синтаксическое дерево и сделать выводы. Сейчас это кажется какой-то элементарщиной, но тогда - это требовало дополнительных вычислений. По поводу итераторов. Вот есть два метода: printUsers(Iterable users) updateUsers(List users) И есть такие переменные: ArrayList users = new ArrayList(); var varUsers = new ArrayList(); А теперь представь разницу в вызове этих методов. Но это ещё не всё. В джаве, в отличии от того же Тайпскрипта, довольно таки скудные возможности работы с типами. И когда в ТС начинаешь комбинировать типы - то никаких бы сил не хватило дублировать их ещё и при объявлении переменной. Да и в целом, смотреть на объявление типа List - это такое себе подспорье.
@@gatos-su "Объявление типа переменной было нужно, чтобы упростить компилятор, так как машины тех лет были несказанно слабее нынешних. " - ссылку можно? ну чтобы без твоих фантазий. (И ссылку не про объем памяти) а про технические решения. И еще приведи хотя бы 1 компилятор (а лучше 2) старше java которые уже поддерживали и строгую типизацию и var - чтобы твои фантазии вообще разрушились.
@@gatos-su если единственная ссылка подтверждающая твои слова это отсылка к скорости компиляции scala или котлин то пожалуйста не пиши больше комментариев. спасибо.
согласен, уже раз пять пытался писать var, но через 3 строчки понимал что читать это невозможно и ставил нормальные типы. Как было сказано, мы читаем слева направо и проблема в том что нам чаще не интересна конкретная имплементация, а не интерфейс с которым мы будем работать Поэтому идея оказалась провальной, тут даже не в реализации проблема, а в том что мы собственоручно удаляем информацию об интерфейсе. Слава богу я еще много кода с этим не видел :)
@@glebbondarenko67 что Котлин, что C#, что некоторые другие языки с выводом типов прекрасно читаются. Просто надо давать функциям и переменным разумные названия. Тогда не будет приходиться задумываться о типах каждой переменной в коде.
я джун, но на сто процентов с тобой согласен. Один раз даже пришлось спорить с намного более опытным разработчиком и на таких же аргументах как у тебя доказывать, что var - это зло (в 90% случаев). Читать код с варами это просто пытка, особенно когда еще хочется перейти в сам класс, который скрывается за варом. С явно указаными типами ctrl+click и перескочил, а попробуйте с варом....
"заставь дурака богу молиться - он себе лоб расшибет" var это годная тема для осмысленного использования в отдельных участках кода, чтобы лишний раз не писать кишки из каких нибудь длинных названий и цепочки вложенных классов и генериков, если важна конкретика или на важном участке кода создается неразбериха, то вар не пишем = profit!
тип переменной обычно понятен из контекста. если это не так, то ты делаешь что-то не то. переменные не создаются от балды, у них есть предназначение, и это предназначение диктует тип. твои примеры малодоказательны: примеры с entySet и singleton это типичные примеры, где всё ясно из контекста. а за остальное тебя будут бить. возможно даже ногами. List - та хрень из-за которой появились генерики. старшие коллеги быстро объяснят тебе почему так делать нельзя. с матами и подзатыльниками для лучшего запоминания. а когда ты попытаешься доказать необходимость переменной, которая может принимать либо число либо текст, то тебя пошлют в наркодиспансер за справкой. в примере с юзером не ясно что ты пытаешься доказать: createUser создаёт юзера. если это не так, то твои коллеги будут недовольны. а значит в переменной будет юзер и значит функция будет вызвана та, где в параметрах юзер. и только когда ты специально указал, что это не юзер а сериалайзабел, только тогда была вызвана другая функция. тут всё сработало предсказуемо.
@@kotojava в котлине тип указывается только там, где нет присвоения - в параметрах или отложенных переменных. и никаких проблем с пониманием кода. ну, разве что некоторый "гений" (скорее всего ты из прошлого) решил повыпендриваться и написал гениальнейший код, который настолько гениален, что тебе нужно время, чтоб понять, что эта хрень делает.
А какая сакральная причина знать тип? Вам не хватает названий? Если не хватает названий (переменных, функций), тогда уже вопросы не к var, а к названиям
знать тип надо, иначе что ты дальше будешь делать с этой переменной? В Visual Studio можно включить добавление типа за var, и если уж совсем нужно то Ctrl + ., enter, и дальше F12. PS я имею ввиду что IDE будет показывать правильный тип после var мелким шрифтом. Очень удобно.
@@kotojava а где я писал про то, что в именах нужно писать название типа?) хотя, кстати, так поступили в microsoft, но сейчас не об этом. суть в том, что название переменной и ее методов должно быть говорящим, будь то даже `vasya_pupkin.eat(apple);` логично же, что vasya_pupkin - это не бульдозер, а apple - это яблоко, а не компания?
я не очень понял почему не отправился мой комментарий, но переписывать все не буду, просто скажу: на сколько важно знать какие типы в данном примере? vasya.eat(apple);
рукалицо. если ты делаешь что-то, что не может поместиться в твоей голове, то ты идиот - разбей проблему на удобоваримые части и обрабатывай по очереди. "разделяй и властвуй" это один из самых основных принципов программирования.
@@kotojava он показывается, но мы же его не пишем. В итоге и тип видим и пишем сокращённо. Тут скорее вопрос привычки как читать. Хотя конечно остаётся проблема читаемости чужого кода при ревью
@@kotojava нужен чтобы не дублировать одно и то же, тип будет просто подсвечен в тени путем угадывания. И если произойдет смена типа, нам не придется менять его во всех местах, где объявили до этого. Такая же штука реализована в TypeScript и kotlin и все ок с отрисовкой типов в идее. Тут скорее проблема не в фиче, а в IDE.
Даже когдя я только начинал учить джаву, мне было непонятно - на кой хрен этот var? Зачем вносить этот хаос в строго типизированный язык? Make peace - not var
var пишут только особоодарённые. Обычно такие люди ещё и джаву явой называют. С такими в жизни не особо хочется иметь что-то общее, не то что работать.
заходит как-то джава разработчик в бар и говорит бармену - мне пиво пиво новое пиво
Вы затронули очень холиварную тему, приведу аргументы почему использовать var по дефолту это нормальная практика.
1. Использование явного типа может увеличивать когнитивную нагрузку пишущего, поскольку он может не помнить точного название типа, возвращаемого методом, и также вынужден наводиться и проваливаться, чтобы этот тип написать. Это видно даже в Вашем видео, где Вы засомневались в типах и стали проваливаться в их объявления)
2. Когнитивная нагрузка читающего может снижаться, но часто это ничего не дает. Если тип стандартный или читающий с ним хорошо знаком, то его очень легко вывести по контексту. Если же вы не знаете тип, то аннотация разве что поможет Вам провалиться в тип в один клик вместо двух, либо, если повезет, что-то понять из названия типа.
3. Часто читающему и не нужно знать, что за тип используется в данном конкретном месте, потому что по названию переменной в совокупности с названиями используемых методов и так понятно, что данный участок кода делает, если все хорошо названо. В таком случаем тип становится просто визуальным шумом, который только мешает.
4. Подсвечивания типов IDE без их явного прописывания, как Вам уже написали в комментариях, очень хорошая вещь, т.к. она одновременно может снизить нагрузку пишущего, поскольку он может использовать var и снизить нагрузку с читающего, поскольку он видит тип.
5. Автоматический вывод типов - это тенденция в современном программировании. Он появился во многих старых языках (С#, C++, Java), и я не знаю ни одного нового языка, в котором бы его не было, например, он есть в Dart, Kotlin, Rust. Причем в новых языках он рассматривается, как дефолтный вариант, и прописывание типов оставлено для ситуаций, когда вывод не справляется или справляется плохо. Вы показали такие ситуации в видео, однако в большинстве случаев вывод типов справляется достаточно хорошо.
6. Куча языков с динамической типизацией нормально себя чувствовали вообще без аннотаций типов. А после того, как они в них появились (Python, TypeScript) стандартной практикой стало считаться использовать их только в сигнатурах и опять же в спорных ситуациях, где вывод не справляется. В остальных ситуациях используется аналог var из Java.
Вы, конечно, можете ограничить или запретить использовать var в своей кодовой базе, и это будет нормально, но это вопрос стиля, аргументы есть в обе стороны. Поэтому мне кажется странным объявлять практику, которая нравится огромному количеству людей, ошибочной. Мне кажется, что неприятие этой фичи во многом исходит из консерватизма Java программистов. В C#, например, эта фича появилась в 2007 году и всем уже давно ок, а в Java var ввели в 2018 и код написанный на var, может выглядеть, как нарушение всех возможных основ)))
Млин ну серьезно, откуда вы такие беретесь.
>> Использование явного типа может увеличивать когнитивную нагрузку пишущего, поскольку он может не помнить точного название типа,
Код пишется один раз - читается тыщу. Лучше "когнитивно нагрузиться" один раз в процесске писки чем потом постоянно держать тип в башке и гадать "что эта хрень делает".
Рефакторинг "выделение переменной" горячими кнопками очень быстро помогает обьявить тип возвращаемый правой частью. Вся нагрузка пропадает.
>>Если тип стандартный или читающий с ним хорошо знаком, то его очень легко вывести по контексту.
Ну нах..я? Если его просто можно тыпо написать и ничего не вывыдить, фокусируясь но бОльшей задаче.
>>Часто читающему и не нужно знать, что за тип используется в данном конкретном месте, потому что по названию переменной в совокупности с названиями используемых методов и так понятно,...
Чаще нужно, чтобы понимать что происходит и ведеть большую картинку...
Все аргументы справедливы для программок типа Хелло Ворлд.
@@AlSlonex123 Согласен на 100% с каждым пунктом.
"Использование явного типа может увеличивать когнитивную нагрузку пишущего, поскольку он может не помнить точного название типа, " как указание типа увеличивает когнитивную нагрузку? мол если не видишь ничего то и думать не надо?
Спасибо, интересное видео. Я - за var :) Var снижает многословность Java, за которую многие ее ругают. Ну и зачем писать два раза тип переменной - слева и справа?
Пример с пользователем показателен. Проблема не в var, а в ожиданиях. Использование конкретного типа (User) никак проблему решает.
Переходи на котлин, зачем страдать на джаве?
Объявление типа переменной было нужно, чтобы упростить компилятор, так как машины тех лет были несказанно слабее нынешних.
Вместо финал вар, нужно было сделать лет или конст - это да, промах.
Посмотри на те же котлин, с шарп, тайпскрипт - всё ок, проблем с типами не.
Если у тебя есть 2 метода, которые принимают Лист и Итерэйбл, а у тебя переменная АррвйЛист, то тебе нужно кастовать.
Большинство примеров высосаны из пальца и на практике ошибки сразу дадут о себе знать, и вообще так никто не напишет.
Упростить компилятор? В котлине тип тоже слева пишется? Какие два метода? какой итератор? Ты точно правильное видео посмотрел?
@@kotojava Упростить компилятор? - да, представь себе, лет 20 назад 512 мб оперативики - это был шик, процессоры в то время были на несколько порядков медленнее. А чтобы сделать вывод типа - нужно заглянуть дальше в синтаксическое дерево и сделать выводы. Сейчас это кажется какой-то элементарщиной, но тогда - это требовало дополнительных вычислений.
По поводу итераторов.
Вот есть два метода:
printUsers(Iterable users)
updateUsers(List users)
И есть такие переменные:
ArrayList users = new ArrayList();
var varUsers = new ArrayList();
А теперь представь разницу в вызове этих методов.
Но это ещё не всё. В джаве, в отличии от того же Тайпскрипта, довольно таки скудные возможности работы с типами. И когда в ТС начинаешь комбинировать типы - то никаких бы сил не хватило дублировать их ещё и при объявлении переменной.
Да и в целом, смотреть на объявление типа List - это такое себе подспорье.
@@gatos-su "Объявление типа переменной было нужно, чтобы упростить компилятор, так как машины тех лет были несказанно слабее нынешних. " - ссылку можно? ну чтобы без твоих фантазий. (И ссылку не про объем памяти) а про технические решения. И еще приведи хотя бы 1 компилятор (а лучше 2) старше java которые уже поддерживали и строгую типизацию и var - чтобы твои фантазии вообще разрушились.
@@kotojava meta Language, ocaml, хаскель? Ссылку могу дать, далеко ходить не надо: скорость компиляции тех же Скала и Котлин
@@gatos-su если единственная ссылка подтверждающая твои слова это отсылка к скорости компиляции scala или котлин то пожалуйста не пиши больше комментариев. спасибо.
согласен, уже раз пять пытался писать var, но через 3 строчки понимал что читать это невозможно и ставил нормальные типы.
Как было сказано, мы читаем слева направо и проблема в том что нам чаще не интересна конкретная имплементация, а не интерфейс с которым мы будем работать
Поэтому идея оказалась провальной, тут даже не в реализации проблема, а в том что мы собственоручно удаляем информацию об интерфейсе. Слава богу я еще много кода с этим не видел :)
Провальной? Ну если только лично для вас. Меня устраивает. Тем более что на смену джаве приходит котлин со своими var и val
@Das.Kleine.Krokodil все как сказал автор: меньше кода - меньше ясности - ещё тяжелее читать. Так же как в идущем котлине 😂
@@glebbondarenko67 котлин читается прекрасно если писать на нем.
@@glebbondarenko67 что Котлин, что C#, что некоторые другие языки с выводом типов прекрасно читаются. Просто надо давать функциям и переменным разумные названия. Тогда не будет приходиться задумываться о типах каждой переменной в коде.
я джун, но на сто процентов с тобой согласен. Один раз даже пришлось спорить с намного более опытным разработчиком и на таких же аргументах как у тебя доказывать, что var - это зло (в 90% случаев). Читать код с варами это просто пытка, особенно когда еще хочется перейти в сам класс, который скрывается за варом. С явно указаными типами ctrl+click и перескочил, а попробуйте с варом....
упаси бог от джунов, которые спорят со словами "smth - это зло"
Какие проблемы с var? Ctrl-left click точно так же переходит а нужный класс.
"заставь дурака богу молиться - он себе лоб расшибет"
var это годная тема для осмысленного использования в отдельных участках кода, чтобы лишний раз не писать кишки из каких нибудь длинных названий и цепочки вложенных классов и генериков, если важна конкретика или на важном участке кода создается неразбериха, то вар не пишем = profit!
Ну увидели, что Set параметризован вот таким типом. И что это дает? Это оиносится к первому "контрпримеру".
тип переменной обычно понятен из контекста. если это не так, то ты делаешь что-то не то. переменные не создаются от балды, у них есть предназначение, и это предназначение диктует тип.
твои примеры малодоказательны:
примеры с entySet и singleton это типичные примеры, где всё ясно из контекста.
а за остальное тебя будут бить. возможно даже ногами. List - та хрень из-за которой появились генерики. старшие коллеги быстро объяснят тебе почему так делать нельзя. с матами и подзатыльниками для лучшего запоминания.
а когда ты попытаешься доказать необходимость переменной, которая может принимать либо число либо текст, то тебя пошлют в наркодиспансер за справкой.
в примере с юзером не ясно что ты пытаешься доказать: createUser создаёт юзера. если это не так, то твои коллеги будут недовольны. а значит в переменной будет юзер и значит функция будет вызвана та, где в параметрах юзер. и только когда ты специально указал, что это не юзер а сериалайзабел, только тогда была вызвана другая функция. тут всё сработало предсказуемо.
В 2024 версии код ревью можно делать внутри IDE
белая тема в IDE и почему она скорее всего тебе не нужна
каждый день использую var в C# )
В С# давно это стало стандартом. На Котлине с этим проблем нет. В Java вечно какие-то проблемы с использованием новых фичей)
в котлине тип указывается справа. зачем нужна эта фича, что она дает?
@@kotojava видимо для различия var и val
@@kotojava в котлине тип указывается только там, где нет присвоения - в параметрах или отложенных переменных. и никаких проблем с пониманием кода. ну, разве что некоторый "гений" (скорее всего ты из прошлого) решил повыпендриваться и написал гениальнейший код, который настолько гениален, что тебе нужно время, чтоб понять, что эта хрень делает.
var в целом прикольно. Опционально
А какая сакральная причина знать тип? Вам не хватает названий? Если не хватает названий (переменных, функций), тогда уже вопросы не к var, а к названиям
знать тип надо, иначе что ты дальше будешь делать с этой переменной? В Visual Studio можно включить добавление типа за var, и если уж совсем нужно то Ctrl + ., enter, и дальше F12.
PS я имею ввиду что IDE будет показывать правильный тип после var мелким шрифтом. Очень удобно.
@@mysorrowangel а что даст название типа в хорошем коде? Банальный пример
var a = 1.4;
var b = 2;
System.out.print(a + b);
Типы писать в переменных и названиях методов ? Серьезно?
@@kotojava а где я писал про то, что в именах нужно писать название типа?) хотя, кстати, так поступили в microsoft, но сейчас не об этом.
суть в том, что название переменной и ее методов должно быть говорящим, будь то даже
`vasya_pupkin.eat(apple);`
логично же, что vasya_pupkin - это не бульдозер, а apple - это яблоко, а не компания?
я не очень понял почему не отправился мой комментарий, но переписывать все не буду, просто скажу:
на сколько важно знать какие типы в данном примере?
vasya.eat(apple);
как это не нужно?
Помоему чуваки которые топят за var ничего более сложного чем то что можно целиком держать в голове не делали.
рукалицо. если ты делаешь что-то, что не может поместиться в твоей голове, то ты идиот - разбей проблему на удобоваримые части и обрабатывай по очереди. "разделяй и властвуй" это один из самых основных принципов программирования.
Это же все просто проблемы ide, которая не подсвечивает тип у var
те нужно иметь var и еще подсвечивать тип?
@kotojava именно так и сделано в андроид студии и котлине
@@densquek1753 зачем тогда var нужен если тип все равно показывается? для снижения читаемости?
@@kotojava он показывается, но мы же его не пишем. В итоге и тип видим и пишем сокращённо. Тут скорее вопрос привычки как читать. Хотя конечно остаётся проблема читаемости чужого кода при ревью
@@kotojava нужен чтобы не дублировать одно и то же, тип будет просто подсвечен в тени путем угадывания. И если произойдет смена типа, нам не придется менять его во всех местах, где объявили до этого.
Такая же штука реализована в TypeScript и kotlin и все ок с отрисовкой типов в идее. Тут скорее проблема не в фиче, а в IDE.
Вор 😂😂😂😂😂
почему?
Вар в законе
Даже когдя я только начинал учить джаву, мне было непонятно - на кой хрен этот var? Зачем вносить этот хаос в строго типизированный язык?
Make peace - not var
так строгость типизации не меняется
var пишут только особоодарённые. Обычно такие люди ещё и джаву явой называют. С такими в жизни не особо хочется иметь что-то общее, не то что работать.
жесть. и кому то ведь с тобой работать приходится)