интересно, спасибо. Вообще было бы интересно больше видео про разбор ошибок, хорошие и плохие практики, почему какой-то код написан не правильно и почему и как правильно и почему. Как-то так
Любому разрабу полезно покодить на Си. Вот для того, чтобы внимательность натренировать. Segmentation fault и вообще, ручная работа с памятью - реально тренирует внимательность. И проблема налл сама собой лечится, вы будете чувствовать пятой точкой, где может быть проблема. Уже работая на PHP, Java, JS и так далее. Эти языки расслабляют, после Си. А у меня много сишного кода в продакшне - знаю, о чем говорю. Не то, чтобы призываю к чему-то, просто для развития, на Си покодить полезно. Без фанатизма, просто базу дает хорошую, и по ОС - процессы, потоки, память, и по сети - ТСП, УДП. И вообще, как работает компьютер.
Согласен, Си - это маст хэв попробовать. Сам начинал с JS - непонятно было много чего, тот же Array вовсе не аррэй. А когда потрогал немного Си - сразу многое прояснилось. А Сергею спасибо. Хотелось бы еще таких уроков.
Шо так проверять на налл, шо иначе проверять на емпти. Но, зато ввели дополнительный класс и якобы избавились от налл, заменив его суррогатом в виде Оптионал. Чем всех так тот налл пугает, на этапе отладки забытые проверки отлавливаются и доставляются. Может быть, я однобоко смотрю на проблему. Я за безопасный и надежный код.
Здравствуйте. А как насчет инициализации объектов по требованию во время выполнения программы. С null это очень удобно. В методе проверил на null. Если ссылка на null тут же инициализировал и все. Объекты создались и далее уже эта проверка будет запрещать ненужное пересоздание объектов при вызове этого метода. Или есть какая альтернатива? Я не особо опытный в этом вопросе но как по мне final - не вариант, так как он сразу потребует создать полноценный объект. А это + к времени загрузки.
Знаю случай когда вопрос о том ставить ли final перешёл в серьёзные дрязги в команде. Лично я убеждён что final для локальных переменных это пустая трата 6 символов. За много лет работы не встречал таких случаев, чтобы final от чего то спас, все гипотетически примеры очень надуманные.
@@Das.Kleine.Krokodil Ну как если бы я хотел что-то сделать с переменной и не смог потому что она final и я сразу прозрел и осознал свою ошибку. Если мне нужно изменить программу - я точно знаю что я делаю, и мне придется потратить немного лишнего времени чтобы удалить final. То есть мало того что final создает ненужный шум в коде, я еще должен тратить время на то чтобы добавлять и удалять его.
тем не менее, очевидно, что Optional ничего не решает в части null safety, и нет никакой разницы возвращается String или Optional, и первое и второе может быть null.. таким образом, все сводится к джентельменскому соглашению, что возвращается не null, но если так, пользы от Optional нет - просто обертка с дополнительными методами и только
Не согласен, это разные вещи. Если из метода может вернутся null и не null, и это является нормальной ситуацией, то тогда везде в коде нужно ставить проверку. И та и другая ситуация не является ошибкой. Если из метода возвращается Optional, то наличие там null вместо Optional нормальной ситуацией не является. Проверок ставить не нужно, приложение должно падать.
Что за чушь.... Null это не проблема а возможность. Если там по ссылке чего то нет - это информация и тупо ее скрывать не лучший вариант. Нормальные IDE (типа Eclipse) это показывают в простых случаях - когда ты обращаешься к не инициализарованной переменной. Во всех иных случаях это сигнал, что что-то пошло не так, и он должен быть явно обработан. Not nullable переменные это просто заметание мусора под ковер - проблема просто выскочит у тебя в другом месте.
Абсолютно согласен. Я столкнулся с этой ситуацией, когда перешел на spring boot. Вызывается метод, но ничего не происходит. Оказалось, что spring оборачивает мой код без каких-либо @NotNull и, если видит, что объект == null, то код не выполняется. Хуже не придумаешь, NPE показывает проблему.
@@arhitutorials А смысл? Это всего лишь значение, которое о чем-то говорит, точно так же ты мог бы захотеть писать код так, чтобы чтобы у тебя не было скажем значения 2... :-)
А не расскажешь, что eclipse подскажет при обращении к БД, когда заранее неизвестно, лежит там объект с каким то идентификатором или нет? Если к кэшу. Или к еще целой куче вещей, которые могут что-то вернуть, а могут и не вернуть, потому что нечего. Optional служит не для заметания мусора под ковер, а для удобной работы с объектами, наличие которых опционально и может варьироваться в тот или иной момент времени. Более того, он как раз таки содержит аж целый набор методов, для обработки случаев отсутствия объекта, поэтому к чему тут идут разговоры о заметании мусора под ковер - вообще не ясно
А, в чем проблема добавить проверку на null? Ну, серьёзно! Что за нытье? Ты программист, ты должен писать код,который не падает. Ты должен предусмотреть не только все случаи, но и уж тем более проверки на 0, null, отрицательные значения, провериять если нужно пользовательский ввод...
Если б среднестатистический программист мог все предусмотреть, то багов бы не было. А они есть, причем даже в серьезных продуктах от крутых разработчиков. Раз нельзя полностью избавиться от ошибок в коде, то надо хотя бы принять меры, чтоб их было меньше.
В наших квартирах есть розетки и это серьезная проблема. Если в розетку сунуть палец, то может поразить электрическим током. Проблема заложена дизайне электросетей и оборудование обрастает разными шторками, заглушками и диффавтоматами, но все равно, иногда электрик что-либо упускает, и нет-нет да и кто-то попадает под напряжение. В других культурах отказались от розеток и пляшут вокруг костров в набедренных повязках... А представляете, если у вас дома есть молоток? Это же можно себе гвоздь забить в палец?!!! А уксус с ацетоном и марганцовка? Ими же можно напиться и умереть в страшных муках! А еще, в наших домах есть газовые плиты... В общем, null - зло, отсутствие статической типизации - зло... Постойте, а как джаваскрипт стал самым популярным языком на планете? Человечество опасносте, надо его срочно запретить!
Джаваскрипт стал популярным, потому что у него нет альтернативы. Другие языки браузеры не понимают. При этом язык не очень удачный. Разработчики вынуждены писать юнит-тесты для проверки того, что в других языках проверяет статическая типизация - это достоинством едва ли можно назвать.
интересно, спасибо. Вообще было бы интересно больше видео про разбор ошибок, хорошие и плохие практики, почему какой-то код написан не правильно и почему и как правильно и почему. Как-то так
Да ладно , месяц спустя ))) ,
я уже подумал плохое случилось , очень рад что нет
надеюсь у тебя все хорошо ,
Очень полезный урок. Спасибо большое!
А я уже думала пилить Optional везде, где можно. Передумала! Отличное видео.
Сергей, вы такой крутой мужик, спасибо!!!
Круто! Спасибо за такие "фишечки"!
Привет из Флориды! Спасибо!
Спасибо большое! Очень рада Вас снова слышать. 🙏
Спасибо огромное! На курсах так доступно не обьясняют!
Любому разрабу полезно покодить на Си.
Вот для того, чтобы внимательность натренировать.
Segmentation fault и вообще, ручная работа с памятью - реально тренирует внимательность.
И проблема налл сама собой лечится, вы будете чувствовать пятой точкой, где может быть проблема.
Уже работая на PHP, Java, JS и так далее.
Эти языки расслабляют, после Си.
А у меня много сишного кода в продакшне - знаю, о чем говорю.
Не то, чтобы призываю к чему-то, просто для развития, на Си покодить полезно.
Без фанатизма, просто базу дает хорошую, и по ОС - процессы, потоки, память, и по сети - ТСП, УДП. И вообще, как работает компьютер.
Согласен, Си - это маст хэв попробовать. Сам начинал с JS - непонятно было много чего, тот же Array вовсе не аррэй. А когда потрогал немного Си - сразу многое прояснилось. А Сергею спасибо. Хотелось бы еще таких уроков.
А сишники друг другу так говорят про ассемблер. А 1сники друг другу так говорят про жаву
Сергей, спасибо за ваши уроки.
Класс!!! Спасибо за видео и пищу к размышлению ✊
Рахметы. Идем в писать стартап))))
спасибо тебе святой человек) обожаю твою подачу.
Как всегда, замечательное видео, большое спасибо!
Спасибо большое науку.
У Вас хорошие ролики.
В целом очень полезный урок. Только одно возражение по поводу @NotNull аннотации - описание в комментарии к Sergey Sukhotsky.
Познавательно! Спасибо!
Надеюсь у вас там все хорошо!
Спасибо. Хорошо бы было добавить про Objects.requireNonNull() и Objects.requireNonNullElse()
Спасібо, было интересно
класс, очень интересно
Спасибо за урок
Optional - это налл, в профиль.
Вместо налл появляется емпти - браво!
Шо так проверять на налл, шо иначе проверять на емпти.
Но, зато ввели дополнительный класс и якобы избавились от налл, заменив его суррогатом в виде Оптионал.
Чем всех так тот налл пугает, на этапе отладки забытые проверки отлавливаются и доставляются.
Может быть, я однобоко смотрю на проблему.
Я за безопасный и надежный код.
Здравствуйте. А как насчет инициализации объектов по требованию во время выполнения программы. С null это очень удобно. В методе проверил на null. Если ссылка на null тут же инициализировал и все. Объекты создались и далее уже эта проверка будет запрещать ненужное пересоздание объектов при вызове этого метода. Или есть какая альтернатива? Я не особо опытный в этом вопросе но как по мне final - не вариант, так как он сразу потребует создать полноценный объект. А это + к времени загрузки.
Если удобно, то почему бы нет.
500 лайк с меня!
Знаю случай когда вопрос о том ставить ли final перешёл в серьёзные дрязги в команде.
Лично я убеждён что final для локальных переменных это пустая трата 6 символов. За много лет работы не встречал таких случаев, чтобы final от чего то спас, все гипотетически примеры очень надуманные.
Полностью с тобой согласен :)
"не встречал таких случаев, чтобы final от чего то спас"
Как вы определили, что final не спас от чего то?
@@Das.Kleine.Krokodil Ну как если бы я хотел что-то сделать с переменной и не смог потому что она final и я сразу прозрел и осознал свою ошибку. Если мне нужно изменить программу - я точно знаю что я делаю, и мне придется потратить немного лишнего времени чтобы удалить final. То есть мало того что final создает ненужный шум в коде, я еще должен тратить время на то чтобы добавлять и удалять его.
@@antonio82917 по вашим словам вы как правило не ставите финал, поэтому противоречие
Спасибо!
Посмотрел ролик, и еще раз повторюсь: "Какой Kotlin оху...замечательный!"
Спасибо
в чем прикол использовать optional, увеличивая нагрузку, если можно вручную сделать проверку?
А как узнать, где нужно делать проверку и где не нужно?
На данный момент востребованы java Android (Junior) разработчики или только kotlin?
На данный момент без Котлина шансов нет.
Старый код на джаве тоже нужно кому-то поддерживать
Говорю про РЕГИОН, у нас стабильные крупные работодатели много платят именно джавистам, котлин в основном в стартапах.
@@arhitutorials значит нужно на него потихоньку переходить
@@ankudinova существует много разрабов, которые умеют джаву, ведь раньше только она и была. теперь требуется только котлин.
тем не менее, очевидно, что Optional ничего не решает в части null safety, и нет никакой разницы возвращается String или Optional, и первое и второе может быть null.. таким образом, все сводится к джентельменскому соглашению, что возвращается не null, но если так, пользы от Optional нет - просто обертка с дополнительными методами и только
Не согласен, это разные вещи.
Если из метода может вернутся null и не null, и это является нормальной ситуацией, то тогда везде в коде нужно ставить проверку. И та и другая ситуация не является ошибкой.
Если из метода возвращается Optional, то наличие там null вместо Optional нормальной ситуацией не является. Проверок ставить не нужно, приложение должно падать.
@@arhitutorials
не понял в чем не согласен, все тобой написанное никак не противоречит, написанному мной
Если кто-то будет смотреть код, то ему через Йода запись намекнуть)
Лучший способ избежать NPE на джаве - перестать писать на джаве и перейти на Котлин)
Особо талантливые девелоперы ловят NPE и на Котлине)
это что система удалила 1 мой коментарий или кто то ручками ?
Вижу два комментария, ничего не трогал. Пока что все нормально.
Что за чушь.... Null это не проблема а возможность. Если там по ссылке чего то нет - это информация и тупо ее скрывать не лучший вариант. Нормальные IDE (типа Eclipse) это показывают в простых случаях - когда ты обращаешься к не инициализарованной переменной. Во всех иных случаях это сигнал, что что-то пошло не так, и он должен быть явно обработан. Not nullable переменные это просто заметание мусора под ковер - проблема просто выскочит у тебя в другом месте.
Я не предлагаю скрывать null. Я предлагаю, насколько это возможно, писать код так, чтоб null принципиально не мог появится.
Абсолютно согласен. Я столкнулся с этой ситуацией, когда перешел на spring boot. Вызывается метод, но ничего не происходит. Оказалось, что spring оборачивает мой код без каких-либо @NotNull и, если видит, что объект == null, то код не выполняется. Хуже не придумаешь, NPE показывает проблему.
@@arhitutorials А смысл? Это всего лишь значение, которое о чем-то говорит, точно так же ты мог бы захотеть писать код так, чтобы чтобы у тебя не было скажем значения 2... :-)
А не расскажешь, что eclipse подскажет при обращении к БД, когда заранее неизвестно, лежит там объект с каким то идентификатором или нет? Если к кэшу. Или к еще целой куче вещей, которые могут что-то вернуть, а могут и не вернуть, потому что нечего. Optional служит не для заметания мусора под ковер, а для удобной работы с объектами, наличие которых опционально и может варьироваться в тот или иной момент времени. Более того, он как раз таки содержит аж целый набор методов, для обработки случаев отсутствия объекта, поэтому к чему тут идут разговоры о заметании мусора под ковер - вообще не ясно
Танкист!
А, в чем проблема добавить проверку на null? Ну, серьёзно! Что за нытье? Ты программист, ты должен писать код,который не падает. Ты должен предусмотреть не только все случаи, но и уж тем более проверки на 0, null, отрицательные значения, провериять если нужно пользовательский ввод...
Если б среднестатистический программист мог все предусмотреть, то багов бы не было. А они есть, причем даже в серьезных продуктах от крутых разработчиков. Раз нельзя полностью избавиться от ошибок в коде, то надо хотя бы принять меры, чтоб их было меньше.
В наших квартирах есть розетки и это серьезная проблема. Если в розетку сунуть палец, то может поразить электрическим током. Проблема заложена дизайне электросетей и оборудование обрастает разными шторками, заглушками и диффавтоматами, но все равно, иногда электрик что-либо упускает, и нет-нет да и кто-то попадает под напряжение. В других культурах отказались от розеток и пляшут вокруг костров в набедренных повязках...
А представляете, если у вас дома есть молоток? Это же можно себе гвоздь забить в палец?!!! А уксус с ацетоном и марганцовка? Ими же можно напиться и умереть в страшных муках! А еще, в наших домах есть газовые плиты...
В общем, null - зло, отсутствие статической типизации - зло... Постойте, а как джаваскрипт стал самым популярным языком на планете? Человечество опасносте, надо его срочно запретить!
Джаваскрипт стал популярным, потому что у него нет альтернативы. Другие языки браузеры не понимают. При этом язык не очень удачный. Разработчики вынуждены писать юнит-тесты для проверки того, что в других языках проверяет статическая типизация - это достоинством едва ли можно назвать.
@@arhitutorials Бедные, бедные джаваскрипт-разработчики, так сильно страдают, и дни и ночи грезят о лучшем языке.... XD
@@janedoe6182 Именно так. Иначе зачем были созданы TypeScript, CoffeScript и Dart?)
@@arhitutorials И как, сильно эти языки, особенно CoffeScript и Dart, обогнали JS по популярности?
@@janedoe6182 на ts переходят активно
Спасибо! Очень доходчиво
Спасибо.
Спасибо
Спасибо
Спасибо