8:43 - почему ты ничего не сказал про дубляж кода с множественными if-else. Можно было бы, например, завести словарь, где ключ - это текущий токен (Current), а значение, это SyntaxKind. Тогда можно было бы вызывать return new... лишь один раз вообще без if.
10:00 Не нравится такое решение, когда в свойство прячут функционал. Спрятал вызов метода Peek(0) в Current, и теперь, в методе Parse, в цикле while, он дважды вызывает геттер Current, вызывая два раза Peek(0), где получает 2 результата от геттера. (А он ведь ещё и в NextToken по новой Current получает, и всё это в том же цикле while вызывает, и по итогу получает множество результатов Current, а не один текущий, с которым работает цикл...) Безопасней было бы один раз получить Current и использовать в коде, чем два потенциально разных результата. И об этом нужно помнить, особенно во всяких многопоточных приложениях.
и так программируют в Microsoft... а мы потом жалуемся еще "чё так глючит"... еще опасность, что этот микрософт паразит кодит свой компилятор... опять новый язык придумают, что бы народ поперся его учить, и так по кругу.
Очень много вопросов к этому коду, просмотрел на скорости х2 по диагонали, и что мне бросилось в глаза сходу, что было пропущено автором. Из серии "как явно делать не стоит и не следует повторять всё за "Профи"". Отрывок с 8:40 по 8:43, всего лишь в одном фрагменте кода. 1. Очень много разносортных классов в одном файле (там же и enum прям посреди файла вчёсан). Старайтесь этого избегать и сегрегировать по отдельным файлам. Если у вас в проекте достаточно много классов, замучаетесь. Проверено опытом. Даже малые отдельные классы старайтесь разносить по разным файлам. 2. Не заметил ни одного #region в таком огромном файле кода. Это позволяет лучше структурировать файл и упорядочивать код внутри самого файла и классов. 3. Мой учитель по "погромированию" мне не раз говорил: "если код отдельного метода не помещается на одном экране монитора (пусть будет 24дюйма) и требует его сильно скролить, то это говорит о том, что этот метод надо разбивать на подметоды, где каждый подметод будет делать конкретную функциональность, исходный же метод приобретёт красивую, короткую и понятную структуру. 4. 135 и 136 строки. Ведь сам автор говорит (где-то вначале ролика), что если тип переменной нельзя понять по правой части выражения, то использовать var не рекомендуется. Почему-то здесь он решил не заострить на этом внимания. 5. Ну и "выколи глаз" прям совсем: строки 153-166 if else if else if else if.... Если вы пишите if else if это уже явный признак того, что вы что-то делаете не так. Почему бы switch не использовать? Возможно стоит использовать фабрику, но для этого нужны исходники, чтобы сказать наверняка. + null в конце каждого return'a в конструкторе SyntaxToken прямо кричит "напиши перегруженный конструктор" 6. Возможно притянуто за уши, но опять же эта лесенка нарушает принцип O из SOLID («программные сущности … должны быть открыты для расширения, но закрыты для модификации».). Т.е. если нам вдруг потребуется добавить новый токен (например "^"), то нам потребуется лезть в исходники, что явно не рекомендуется, вместо расширения функционала. Если это не предусмотрено исходным ТЗ, то необходимо объяснить, что в целом должен делать данный проект. P.S. Дальше смотреть не стал. Желательно прикладывать ссылку на исходники, чтобы можно было посмотреть спорные места не по видео, а в проекте + краткое описание ТЗ.
@@Morte77777 1. лично мне сложнее разобраться в куче файлов, чем найти enum внутри другого файла. 2. region как и комментарии многие не одобряют, понятнее разнести на разные сущности чем работать с region. 5. свич такое же зло как иф элс которые реализован как свич. полностью согласен с 6 пунктом
@@Captain_Rederick Ой,ну ты то щас пойдешь и винду оптимизируешь,гений.Ты как сварливая бабка,увидел какой-то небольшой недочет и все,ой какой же он даун,вот это из-за таких как он все у нас плохо,бла-бла-бла
Да бесполезный полностью. Берешь, читаешь книжку - и пожалуйста! Создатели языка придумали readonly - пользуйся! Про инкапсуляцию прочитал - делай! Это дрочево над кодестайлом или расстановкой const или, чего хуже, ошаблониванию кода - это не про разработку. Это про онанизм. Автор неоднократно признался, что делает это, но скорее всего, ему это не требуется физически, поскольку он каждый раз делает это со своим кодом.
Я бы вместо IEnumerable для public API всё таки использовал IReadOnlyList в данном случае. IEnumerable - это всё таки абстракция не коллекции, а перечисления (внезапно), из-за чего клиент может для перестраховки вызывать дополнительные вещи типа ToList() или ToArray) Также IReadOnlyList имеет свойство Count.
@@debasher Да ладно Вам)) В список можно добавить объекты, удалить, заменить, очистить весь список + по индексатору сделать замену. Это же сама суть List'a) Наверное, Вы про что-то другое подумали?)
IReadOnlyList не даст вам lazy evaluation behaviour, вам придется аллоцировать память внутри метода под ту коллекцию которую вы собираетесь возвращать.
@@dubovikovpv Это просто интерфейс - абстракция. В видео для List'a лучше её использовать, нежели IEnumerable, чтобы у потребителя класса не возникало лишних вопросов, о том как обработать данную коллекцию.
У list есть метод AsReadOnlyList. Он вернет другой объект, который уже не получится принудительно скастить в list. Возвращать list в виде IEnumerable мило конечно, но наивно.
Вообще, если возвращать лист под интерфейсом енумерабла - для особо настырных говнокодеров все равно остаётся возможность его менять (никто ж не мешает пытатся привести интерфейсу ссылку к конкретному типу). Тут лучше делать list.AsReadonly() - будет создана оболочка только для чтения, которую ни к чему особо не приведешь, как ни старайся
Деструктор как вызовется если объект имеет ссылку на event другого объекта? Если подписка нужна весь жизненный цикл объекта - лучше реализовать IDisposable и через Dispose() отписываться. Явно самому вызывать Dispose() или отдать на откуп, например, Zenject у.
@@goodcat1634 верно, в таком сценарии деструктор не вызовется, но стоит уточнить почему именно. Не потому что подписчик имеет ссылку на ивент паблишера, а наоборот. Объект Publisher, который предоставляет ивент, при подписке на этот ивент другим объектом Subscriber, начинает хранить ссылку на метод-обработчик Subscriber'а. То есть Паблишер удерживает Сабскрайбера от очистки сборщиком мусора, так как содержит ссылку на него, а не наоборот. Следовательно GC не сможет очистить Subscriber, пока на него имеется ссылка у Паблишера, значит и деструктор Сабскрайбера не сработает и отписки от ивентов не произойдет, пока жив Паблишер. Дальше зависит полностью от того устраивает это нас или нет.
@@bogdanvacban Да, всё верно, я не точно написал. В общих чертах - ивент это по своей сути обёрнутый делегат, делегат хранит ссылку на экземпляр Subscriber а и адрес метода. Соответственно, GC не очищает, деструктор не срабатывает.
Хотелось бы видеть выделение обсуждаемого куска кода. Хотя бы курсором (как в некоторых моментах этого ролика). Имхо, так будет чуть удобнее, чем ориентироваться по номеру строки.
Кстати в дополнения к sealed классам, на более низком уровне при компиляции sealed классы имеют лучшую оптимизацию. В реальном проекте скорее всего существенной разницы производительности не заметите, но как интересный факт. А переменная readonly не будет отображаться в инспекторе, если проектировать в Unity, поэтому при работе с движками есть немного другая специфика, но в целом практика правильная. По поводу var, я столкнулся на собственном опыте с этой проблемой, когда нужно редактировать большой обьем кода, и var*ы действительно мешают, особенно если часть кода написана командой. Разумеется, чистый код подразумевает и строгую типизацию данных, а var это просто дурной тон. Когда я ставлю var, значит мне просто лень указать тип данных, как правило. ps Ну а else if else if else if else if на 8 минуте кажется забавным, 6 последовательных if*ов) Когда приходиться так делать, значит есть некоторые проблемы в проектировании логики.
@@redcrab5969 посмотрел бегло, а почему я должен изменить свою точку зрения? В js схожий синтаксис, и тоже везде var*ы ставят, там это принято, но почему я должен повторять за ними? Сам по себе js более простой язык и был создан для других целей, 90% кода это код для браузеров, и код достаточно простой и повторяющийся. Что касается скалы, визуально, мне показалось очень похожим на js. Если вы это имели ввиду. ps Вообще, код в скале выглядит как кусок г... мягко сказать, если честно. Не вижу преимуществ, с таким же успехом можно вообще перейти на формулы математики, и писать сразу формулами, кратко, быстро и непонятно)) Он переплюнул даже js, неудивительно, что он непопулярен и я об этом ничего не знал. PPS. Судя из описания, даже сами программисты, которые пишут на скале, не всегда понимают где уместно использовать val а где var, и это написано в первой попавшийся статье про этот язык. Дальше я даже читать не стал) На скале я не понял ни одной строчки кода, в то время как на js читаю код без проблем, не смотря на то, что основной стек и специализация работы у меня связана только с шарпом. Поэтому так и не понял, почему должен поменять свою точку зрения относительно чистоты кода, и использования явно типизированных данных. Для меня в голове есть грань разумного, между сокращением и оптимизацией кода, и полной фигней, которая очевидно запутает даже опытного программиста. Я всегда придерживался именно такой точки зрения, что если код можно прочитать банально как английский текст, значит это хороший код. Если щас все обратно перейдут на формулы как в скале, то мы вернемся обратно в истоки с++ или ниже по структуре и запутанности кода. С# изначально задумывался как улучшенная версия C\С++ грубо говоря, чем собственно и стал в итоге, грамотный код можно легко читать, быстро редактировать, там сделали очень много для того, чтобы улучшить структуру даже самого бездарного кода. Либо я не понял, что вы имели ввиду.
@@АнатолийПетрович-э8ч Scala является статически типизированным языком, во многом похож на java, но в то же время позволяет работать с обобщенным программированием и имеют кучу других плюшек для работы с типами, вроде подразумеваемого преобразования типов - проще говоря, все безопасно и в то же время гибко. "неудивительно, что он непопулярен" - как и многие функциональные языки, в целом его используют те, кому нужна java и фп. "можно вообще перейти на формулы математики" - думаю у вас очень большой опыт в ООП и императивной парадигме программирования, и поэтому у вас такая реакция. "где уместно использовать val а где var" - val - декларативный стиль, var - императивный, действительно, scala не является чисто функциональным. Далее вы написали про то, что Scala хуже js по читаемости, как java-ист вынужден не согласиться. C# в пален синтаксиса похож на С++, java, но синтаксического сахара в нем больше чем в java, есть перегрузка операторов, как в C++ (могу ошибаться), выходит, что java лучше C#? Английский текст же А вообще, мне очень приятно встретить человека на этом канале, с которым можно подискутировать)
@@redcrab5969 синтаксический сахар как раз таки делает язык удобочитаемым, если его использовать с умом, разумеется логически-связанный английский текст это не все, что необходимо для удобочитаемости кода, но это один из "главных пунктов". Я все-же думаю, что рассматривать язык с позиции популярности - это важно, не просто так про Scala знает сравнительно небольшое кол-во людей в IT, и лишь малая часть из тех, кто про него вообще что-то знает, стремятся получить практические навыки работы на нем. Это важный показатель фактического применения языка в бизнесе в целом, которое околонулевое, если сравнивать с другими языками(да, я посмотрел графики "популярности"). Видимо "java и фп" как вы выразились, далеко не всем нужно. И вероятно у него выше порог вхождения, для новичков думаю это будет сложным для понимания, но лично для себя я не понял, зачем вообще этим заниматься и писать что-то на скале, или смотреть в его сторону сравнивать его с С#, коль у них абсолютно разная концепция. Поэтому ваш аргумент, что "стоит посмотреть в сторону Scala и изменить свое мнение" таким образом разрушен) Это как сравнивать малопопулярные узкоспециализированные вещи, с популярными, которые были выстроены десятилетиями на миллионах проб и ошибок. Индустрия в целом сейчас идет к тому, чтобы сделать языки максимально доступными для понимания, легко редактируемыми, с низким порогом вхождения, чтобы в условиях огромной компании можно было бы оперативно корректировать модули проекта, это выгодно в первую очередь для бизнеса, и Майкрософт в том числе это понимает, лучше чем кто либо. К тому-же у языков разный уровень доступа в системе, C# позволяет при желании залезать даже на более низкий уровень работы с памятью устройства и исполнять в своем коде системные инструкции сродни коду С++, ни js, ни scala вам этого сделать не дадут. В C# сохранение некоторых парадигм и паттернов проектирования просто необходимо. Есть существенная разница, когда кодишь под браузер, и когда кодишь на уровне системы, системные приложения. В первом случае наверно не так страшно, если код немного упростить, и писать везде вары. Как я понимаю именно оттуда и пошла такая тенденция, если возвращаться к тому, с чего мы начали диалог.
В плюсах наоборот - везде следует автоматический вывод типа использовать, аналог в шарпе var. Компилятор гораздо лучше знает какой тип выводится, можно запросто нарваться на лишние копирования и тд
думаю сакутин брал только “хорошие примеры кода", не всех же говном поливать ("говноблогеры" != "говнопрограммисты"). я бы лично switch предпочел, потому что более приятно на глаз код будет, нежели такое количество ифов. да и к тому же код повторяющийся(сакутин сам за это кого-то какое-то время назад ругал). я бы вынес результаты (1 и 3 параметра конструктора) в две переменных и, используя эти переменные писал после проверки "...new SyntaxToken(1 переменная, ... , 2 переменная...)...".
Жаль, но для Unity такое использование readonly обычно не актуально. Так как в унаследованных от MonoBehaviour классах нет конструктора, инициализацию полей придётся делать через метод. И в редакторе такие поля не отображаются.
А кто сказал что весь код в Unity нужно писать в наследниках MonoBehaviour? MonoBehaviour это больше часть со видмой частью движка(view) и каких то событий движка.
@@МихаилСуворов-к2щ именно по этой причине я написал «ОБЫЧНО не актуально». Если совсем извратиться, то можно написать игру вообще не используя MonoBehaviour (вернее, один понадобится). Из корневого скрипта собрать разного рода скрипты-контроллеры, которые через какие-нибудь ScriptableObjects соберут ссылки на GameObjectы, аниматоры и прочее. Ну, и использовать один Update() из корневого скрипта. А он уже при необходимости вызовет Update() всех остальных скриптов. Как известно, если взять 10 000 объектов в сцене и на каждый из них повесить MonoBehaviour, то все они будут помещены во внутренний список. И при каждом Update() движок будет не просто вызывать каждый из 10 000 объектов, но сначала проверять его наличие в сцене. Поэтому архитектура Unity, основанная на компонентной модели и MonoBehaviour, - это зло. А поэтому надо написать свой MVC-подобный велосипед. Думаете, я брежу? Нет, это краткий пересказ проекта с курсов GeekBrains.
Честно, не смотрю канал. Случайно глянул это видео. Мне не понятно, что значит "стоит перенять 6 вещей"? Да это же аксиома! Это должно ещё на первом курсе быть железобетонно закреплено в мышлении разработчика. Может стоит выпускать видео для разных уровней разработчиков? Лучше с пометкой в названии ролика о уровне сложности. Это видео для тех, кто ещё поля именует, к примеру, не "_counter", а EPSDHSC )) Я когда узнал, у студента, что это за поле такое, ответ просто убил! ) "EPSDHSC - Эта Переменная Служит Для Хранения Счётчика Цикла" Рука лицо одним словом. )))
Ура, наконец видос о работе с кодом) Планируется ли выпускать ролики по книге «элегантные объекты» Егора Бугаенко? Помнится, было на канале тг пару постов, а потом все затихло.
По поводу Linq. Штука очень полезная. Главное быть с ней очень аккуратным в методах которые часто вызываются во время активного геймплея. Был случай когда к коде происходил поиск подходящего эффекта(префаб с партиклами) при помощи Linq и это давало ощутимую нагрузку. В итоге пришлось заменить поиск на взятие эффекта по ключу из словаря. Вообще словари достаточно быстрая штука и для быстрого сопоставления данный лучше использовать их. По крайней мере так показала моя практика.
Слушай, хотел спросить:у меня есть массив обьектов и словарь этих обьектов. Я в void start пихаю в словарь обьект и имя обьекта.А потом получаю обьект с нужным мне именем. Это же лучше чем каждый раз перебирать массив в цикле?
@@-._63 да, получение элемента из словаря по ключу быстрее линейного перебора. Скорость взятия из словаря O(1), линейным поиском из массива - О(n) Там под капотом словарь хитро располагает объекты, и быстро их по хэшу достает, если не ошибаюсь
Забавное различие ) в Котлин sealed жестко регламентирует количество наследников, то есть своего рода расширенный enum. А в С# от sealed class просто нельзя дальше наследоваться? Или можно сделать скажем 3 наследника, а потом уже нельзя будет?
Я написал. Использовал формулы из геометрии и векторной алгебры. Берем точку позиции юнита и точку цели, вычисляем расстояние через корень квадрата разницы координат. Затем вычисляем коэффициент изменения каждой координаты юнита. Это его скорость (или длина отрезка на которую от перемещается в каждом кадре) деленная на расстояние до цели. Теперь этот коэффицинет умножаем на величину каждой координаты и значение прибавляем к каждой координате. Готово.
Вот блин, как же режет слух эта фраза: обучение с нуля с гарантией трудоустройства. Ну серьезно, не делайте из своих зрителей дураков. Такие вещи гарантировать невозможно в принципе, а тем более на онлайн курсе в несколько месяцев. После скиллбокса и гикбрейнса у нас каждый второй гарантирует трудоустройство, только вот что то я не вижу чтобы у нас все стали айтишниками. Даже если это просто рекламный слоган, то это хреновая идея говорить то чего вы не можете выполнить.
"Linq очень удобная штука". Значит код который мы пишем менее удобный. Раз мы не можем сами написать код который для нас будет хотя бы таким же удобным как linq, то может проблема в нас и в нашем коде?
Аналогичный вопрос можно задать относительно количества страниц какой либо книги. В конечном итоге, только читаемость определяет, можно или нет, если код как-то цепляет глаз значит, что-то не так.
Это автор делает для своего удобства, чтобы не бегать по множеству файлов, он сначала построит архитектуру в одном файле, а потом раскидает классы каждый в свой файл
Ставь лайк если формат зашёл, подписывайся если хочешь ещё.
Кинь ссылку на видео, которые ты разбирал, пожалуйста..
Что делать если уже подписан? Отписаться и снова подписаться?
8:43 - почему ты ничего не сказал про дубляж кода с множественными if-else. Можно было бы, например, завести словарь, где ключ - это текущий токен (Current), а значение, это SyntaxKind. Тогда можно было бы вызывать return new... лишь один раз вообще без if.
перестань показывать лицо вместо кода
Формат крутой, только вот по видео кажется, что он не компилятор пишет, а всё-таки синтаксический анализатор.
Вот такой Рома мне нравится. Отличное видео! Ждём разбор тестового :>
Когда увидим код профессионала Романа Сакутина
Ждем
10:00 Не нравится такое решение, когда в свойство прячут функционал.
Спрятал вызов метода Peek(0) в Current, и теперь, в методе Parse, в цикле while, он дважды вызывает геттер Current, вызывая два раза Peek(0), где получает 2 результата от геттера. (А он ведь ещё и в NextToken по новой Current получает, и всё это в том же цикле while вызывает, и по итогу получает множество результатов Current, а не один текущий, с которым работает цикл...)
Безопасней было бы один раз получить Current и использовать в коде, чем два потенциально разных результата.
И об этом нужно помнить, особенно во всяких многопоточных приложениях.
и так программируют в Microsoft... а мы потом жалуемся еще "чё так глючит"... еще опасность, что этот микрософт паразит кодит свой компилятор... опять новый язык придумают, что бы народ поперся его учить, и так по кругу.
Очень много вопросов к этому коду, просмотрел на скорости х2 по диагонали, и что мне бросилось в глаза сходу, что было пропущено автором.
Из серии "как явно делать не стоит и не следует повторять всё за "Профи"".
Отрывок с 8:40 по 8:43, всего лишь в одном фрагменте кода.
1. Очень много разносортных классов в одном файле (там же и enum прям посреди файла вчёсан).
Старайтесь этого избегать и сегрегировать по отдельным файлам. Если у вас в проекте достаточно много классов, замучаетесь. Проверено опытом. Даже малые отдельные классы старайтесь разносить по разным файлам.
2. Не заметил ни одного #region в таком огромном файле кода. Это позволяет лучше структурировать файл и упорядочивать код внутри самого файла и классов.
3. Мой учитель по "погромированию" мне не раз говорил: "если код отдельного метода не помещается на одном экране монитора (пусть будет 24дюйма) и требует его сильно скролить, то это говорит о том, что этот метод надо разбивать на подметоды, где каждый подметод будет делать конкретную функциональность, исходный же метод приобретёт красивую, короткую и понятную структуру.
4. 135 и 136 строки. Ведь сам автор говорит (где-то вначале ролика), что если тип переменной нельзя понять по правой части выражения, то использовать var не рекомендуется. Почему-то здесь он решил не заострить на этом внимания.
5. Ну и "выколи глаз" прям совсем: строки 153-166 if else if else if else if.... Если вы пишите if else if это уже явный признак того, что вы что-то делаете не так.
Почему бы switch не использовать? Возможно стоит использовать фабрику, но для этого нужны исходники, чтобы сказать наверняка.
+ null в конце каждого return'a в конструкторе SyntaxToken прямо кричит "напиши перегруженный конструктор"
6. Возможно притянуто за уши, но опять же эта лесенка нарушает принцип O из SOLID («программные сущности … должны быть открыты для расширения, но закрыты для модификации».). Т.е. если нам вдруг потребуется добавить новый токен (например "^"), то нам потребуется лезть в исходники, что явно не рекомендуется, вместо расширения функционала. Если это не предусмотрено исходным ТЗ, то необходимо объяснить, что в целом должен делать данный проект.
P.S. Дальше смотреть не стал. Желательно прикладывать ссылку на исходники, чтобы можно было посмотреть спорные места не по видео, а в проекте + краткое описание ТЗ.
@@Morte77777 1. лично мне сложнее разобраться в куче файлов, чем найти enum внутри другого файла.
2. region как и комментарии многие не одобряют, понятнее разнести на разные сущности чем работать с region.
5. свич такое же зло как иф элс которые реализован как свич.
полностью согласен с 6 пунктом
@@Captain_Rederick ну шош ты тогда на майкрасофт не работаешь, раз такой умный?
@@Captain_Rederick Ой,ну ты то щас пойдешь и винду оптимизируешь,гений.Ты как сварливая бабка,увидел какой-то небольшой недочет и все,ой какой же он даун,вот это из-за таких как он все у нас плохо,бла-бла-бла
А вот этот обзор кода был интересным и познавательным, побольше бы таких.
Да бесполезный полностью. Берешь, читаешь книжку - и пожалуйста! Создатели языка придумали readonly - пользуйся! Про инкапсуляцию прочитал - делай! Это дрочево над кодестайлом или расстановкой const или, чего хуже, ошаблониванию кода - это не про разработку. Это про онанизм. Автор неоднократно признался, что делает это, но скорее всего, ему это не требуется физически, поскольку он каждый раз делает это со своим кодом.
Да побольше таких выпусков ! =)
Наконец-то) ещё один шаг в правильном направлении) ура!
вот это да, приятно смотреть, без желчи, информация лучше укладывается, супер.
Смотришь тебя и начинаешь плакать над своим кодом 😭
Демонстративно на видео любой может разогнать и показать лучшее) Худшие свои моменты из кода он не показывает ))
Полезное видео. Давай больше видео про код опытных разработчиков!
Лично я очень жду продолжения данного формата, спасибооо
Программист то из Майкрософт, но посмотрите внимательно на его ноутбук
Это обманка чтобы набрать классы
@@MrBoBrilO А, но все равно
Подивись на вікно.
Это маскеровка
Настолько программист майкров, что заебала его винда.
Рома))) Крутейший формат! Спасибо) Даже напоминание о выходе роликов активировал.
Я бы вместо IEnumerable для public API всё таки использовал IReadOnlyList в данном случае. IEnumerable - это всё таки абстракция не коллекции, а перечисления (внезапно), из-за чего клиент может для перестраховки вызывать дополнительные вещи типа ToList() или ToArray) Также IReadOnlyList имеет свойство Count.
Тоже об этом подумал, спасибо 👍 А вот про то, что список можно изменить не знал(
@@debasher Да ладно Вам)) В список можно добавить объекты, удалить, заменить, очистить весь список + по индексатору сделать замену. Это же сама суть List'a) Наверное, Вы про что-то другое подумали?)
IReadOnlyList не даст вам lazy evaluation behaviour, вам придется аллоцировать память внутри метода под ту коллекцию которую вы собираетесь возвращать.
@@dubovikovpv Это просто интерфейс - абстракция. В видео для List'a лучше её использовать, нежели IEnumerable, чтобы у потребителя класса не возникало лишних вопросов, о том как обработать данную коллекцию.
List не реализует IReadOnlyList, там создается новый объект, что в свойствах лучше не делать
Супер полезное видео! Формат просто замечательный. Наверное единственный в своем роде в ру сегменте
Клево) И на код посмотрел, и полезные замечания услышал👍 Можно ссылочку на канал профи?
Суперский ролик, выцепил для себя просто тонну полезных вещей. Нам нужно больше)
8:45 или можно передавать IReadOnlyList, с ним будет удобнее работать. Но ни IEnumarable не IReadOnlyList не защищает от апкаста до IList
По этому кастинг и запрещён
У list есть метод AsReadOnlyList. Он вернет другой объект, который уже не получится принудительно скастить в list. Возвращать list в виде IEnumerable мило конечно, но наивно.
@@rsakutin честно говоря, первый раз слышу про запрет кастинга
@@rsakutin запрещено это на словах, на деле апкастить можно, значит кто-нибудь обязательно так сделает и полетят ошибки
@@usmax А ещё кто-то через рефлексию может залезть и наворотить всё что хочет.
Вообще, если возвращать лист под интерфейсом енумерабла - для особо настырных говнокодеров все равно остаётся возможность его менять (никто ж не мешает пытатся привести интерфейсу ссылку к конкретному типу). Тут лучше делать list.AsReadonly() - будет создана оболочка только для чтения, которую ни к чему особо не приведешь, как ни старайся
Приводим, конвертим всё к базовым типам, в данном случае .ToArray()
Ничего не понимаю, но так интересно!
Наконец то нормальный контент! Можно поесть!
"В конструкторе ненадо подписываться на что-либо. Как вы потом будете отписываться?" (с) Роман
Ну наверное в деструкторах, так?
Подумайте ещё немного
*Weak Reference вынесем за скобки
Деструктор как вызовется если объект имеет ссылку на event другого объекта?
Если подписка нужна весь жизненный цикл объекта - лучше реализовать IDisposable и через Dispose() отписываться. Явно самому вызывать Dispose() или отдать на откуп, например, Zenject у.
@@goodcat1634 верно, в таком сценарии деструктор не вызовется, но стоит уточнить почему именно. Не потому что подписчик имеет ссылку на ивент паблишера, а наоборот.
Объект Publisher, который предоставляет ивент, при подписке на этот ивент другим объектом Subscriber, начинает хранить ссылку на метод-обработчик Subscriber'а.
То есть Паблишер удерживает Сабскрайбера от очистки сборщиком мусора, так как содержит ссылку на него, а не наоборот. Следовательно GC не сможет очистить Subscriber, пока на него имеется ссылка у Паблишера, значит и деструктор Сабскрайбера не сработает и отписки от ивентов не произойдет, пока жив Паблишер.
Дальше зависит полностью от того устраивает это нас или нет.
@@bogdanvacban Да, всё верно, я не точно написал. В общих чертах - ивент это по своей сути обёрнутый делегат, делегат хранит ссылку на экземпляр Subscriber а и адрес метода. Соответственно, GC не очищает, деструктор не срабатывает.
Хотелось бы видеть выделение обсуждаемого куска кода. Хотя бы курсором (как в некоторых моментах этого ролика). Имхо, так будет чуть удобнее, чем ориентироваться по номеру строки.
Да, это планировалось сделать на монтаже, но времени не хватило)
Кстати в дополнения к sealed классам, на более низком уровне при компиляции sealed классы имеют лучшую оптимизацию. В реальном проекте скорее всего существенной разницы производительности не заметите, но как интересный факт. А переменная readonly не будет отображаться в инспекторе, если проектировать в Unity, поэтому при работе с движками есть немного другая специфика, но в целом практика правильная. По поводу var, я столкнулся на собственном опыте с этой проблемой, когда нужно редактировать большой обьем кода, и var*ы действительно мешают, особенно если часть кода написана командой. Разумеется, чистый код подразумевает и строгую типизацию данных, а var это просто дурной тон. Когда я ставлю var, значит мне просто лень указать тип данных, как правило.
ps Ну а else if else if else if else if на 8 минуте кажется забавным, 6 последовательных if*ов) Когда приходиться так делать, значит есть некоторые проблемы в проектировании логики.
Глянь scala, точнее про то, как там происходит работа с переменными, может быть изменишь свою точку зрения
@@redcrab5969 посмотрел бегло, а почему я должен изменить свою точку зрения? В js схожий синтаксис, и тоже везде var*ы ставят, там это принято, но почему я должен повторять за ними? Сам по себе js более простой язык и был создан для других целей, 90% кода это код для браузеров, и код достаточно простой и повторяющийся. Что касается скалы, визуально, мне показалось очень похожим на js. Если вы это имели ввиду.
ps Вообще, код в скале выглядит как кусок г... мягко сказать, если честно. Не вижу преимуществ, с таким же успехом можно вообще перейти на формулы математики, и писать сразу формулами, кратко, быстро и непонятно)) Он переплюнул даже js, неудивительно, что он непопулярен и я об этом ничего не знал.
PPS. Судя из описания, даже сами программисты, которые пишут на скале, не всегда понимают где уместно использовать val а где var, и это написано в первой попавшийся статье про этот язык. Дальше я даже читать не стал) На скале я не понял ни одной строчки кода, в то время как на js читаю код без проблем, не смотря на то, что основной стек и специализация работы у меня связана только с шарпом. Поэтому так и не понял, почему должен поменять свою точку зрения относительно чистоты кода, и использования явно типизированных данных. Для меня в голове есть грань разумного, между сокращением и оптимизацией кода, и полной фигней, которая очевидно запутает даже опытного программиста. Я всегда придерживался именно такой точки зрения, что если код можно прочитать банально как английский текст, значит это хороший код. Если щас все обратно перейдут на формулы как в скале, то мы вернемся обратно в истоки с++ или ниже по структуре и запутанности кода. С# изначально задумывался как улучшенная версия C\С++ грубо говоря, чем собственно и стал в итоге, грамотный код можно легко читать, быстро редактировать, там сделали очень много для того, чтобы улучшить структуру даже самого бездарного кода. Либо я не понял, что вы имели ввиду.
@@АнатолийПетрович-э8ч Scala является статически типизированным языком, во многом похож на java, но в то же время позволяет работать с обобщенным программированием и имеют кучу других плюшек для работы с типами, вроде подразумеваемого преобразования типов - проще говоря, все безопасно и в то же время гибко.
"неудивительно, что он непопулярен" - как и многие функциональные языки, в целом его используют те, кому нужна java и фп.
"можно вообще перейти на формулы математики" - думаю у вас очень большой опыт в ООП и императивной парадигме программирования, и поэтому у вас такая реакция.
"где уместно использовать val а где var" - val - декларативный стиль, var - императивный, действительно, scala не является чисто функциональным.
Далее вы написали про то, что Scala хуже js по читаемости, как java-ист вынужден не согласиться.
C# в пален синтаксиса похож на С++, java, но синтаксического сахара в нем больше чем в java, есть перегрузка операторов, как в C++ (могу ошибаться), выходит, что java лучше C#? Английский текст же
А вообще, мне очень приятно встретить человека на этом канале, с которым можно подискутировать)
@@redcrab5969 синтаксический сахар как раз таки делает язык удобочитаемым, если его использовать с умом, разумеется логически-связанный английский текст это не все, что необходимо для удобочитаемости кода, но это один из "главных пунктов". Я все-же думаю, что рассматривать язык с позиции популярности - это важно, не просто так про Scala знает сравнительно небольшое кол-во людей в IT, и лишь малая часть из тех, кто про него вообще что-то знает, стремятся получить практические навыки работы на нем. Это важный показатель фактического применения языка в бизнесе в целом, которое околонулевое, если сравнивать с другими языками(да, я посмотрел графики "популярности"). Видимо "java и фп" как вы выразились, далеко не всем нужно. И вероятно у него выше порог вхождения, для новичков думаю это будет сложным для понимания, но лично для себя я не понял, зачем вообще этим заниматься и писать что-то на скале, или смотреть в его сторону сравнивать его с С#, коль у них абсолютно разная концепция. Поэтому ваш аргумент, что "стоит посмотреть в сторону Scala и изменить свое мнение" таким образом разрушен) Это как сравнивать малопопулярные узкоспециализированные вещи, с популярными, которые были выстроены десятилетиями на миллионах проб и ошибок. Индустрия в целом сейчас идет к тому, чтобы сделать языки максимально доступными для понимания, легко редактируемыми, с низким порогом вхождения, чтобы в условиях огромной компании можно было бы оперативно корректировать модули проекта, это выгодно в первую очередь для бизнеса, и Майкрософт в том числе это понимает, лучше чем кто либо. К тому-же у языков разный уровень доступа в системе, C# позволяет при желании залезать даже на более низкий уровень работы с памятью устройства и исполнять в своем коде системные инструкции сродни коду С++, ни js, ни scala вам этого сделать не дадут. В C# сохранение некоторых парадигм и паттернов проектирования просто необходимо. Есть существенная разница, когда кодишь под браузер, и когда кодишь на уровне системы, системные приложения. В первом случае наверно не так страшно, если код немного упростить, и писать везде вары. Как я понимаю именно оттуда и пошла такая тенденция, если возвращаться к тому, с чего мы начали диалог.
@@АнатолийПетрович-э8ч ютуб глючит, можно связаться с вам как-то иначе?
Норм картинка и звук. Оставляй такой формат.
Я только что заметил что у Сакутина на руке тату с словом Solve тоже тату есть у бефомета
Контент, которого я ждал! 👍👍👍👍👍👍👍👍👍 КРАСАВА!
Впервые роман сакутин не обсёр код😂
ништяк видос
В плюсах наоборот - везде следует автоматический вывод типа использовать, аналог в шарпе var. Компилятор гораздо лучше знает какой тип выводится, можно запросто нарваться на лишние копирования и тд
Добрая треть видео-введение. Но само видео классное
Роман, хочу тебя попросить снять видео про GODOT ENGINE. Движок 2d, 3d, OpenSource
Когда я увидел превью, я подумал, что это обзор на "Лавку Разработчика", но нет😆
а что с ним не так? я так и не могу до него дотянуться
8:47, Насколько это плохо?, стоит ли этого избегать возможности и можно ли вообще избежать? Почему не switch? Очень много вопросов и не понятно
думаю сакутин брал только “хорошие примеры кода", не всех же говном поливать ("говноблогеры" != "говнопрограммисты"). я бы лично switch предпочел, потому что более приятно на глаз код будет, нежели такое количество ифов. да и к тому же код повторяющийся(сакутин сам за это кого-то какое-то время назад ругал). я бы вынес результаты (1 и 3 параметра конструктора) в две переменных и, используя эти переменные писал после проверки "...new SyntaxToken(1 переменная, ... , 2 переменная...)...".
Жаль, но для Unity такое использование readonly обычно не актуально. Так как в унаследованных от MonoBehaviour классах нет конструктора, инициализацию полей придётся делать через метод. И в редакторе такие поля не отображаются.
А кто сказал что весь код в Unity нужно писать в наследниках MonoBehaviour? MonoBehaviour это больше часть со видмой частью движка(view) и каких то событий движка.
@@МихаилСуворов-к2щ именно по этой причине я написал «ОБЫЧНО не актуально».
Если совсем извратиться, то можно написать игру вообще не используя MonoBehaviour (вернее, один понадобится). Из корневого скрипта собрать разного рода скрипты-контроллеры, которые через какие-нибудь ScriptableObjects соберут ссылки на GameObjectы, аниматоры и прочее. Ну, и использовать один Update() из корневого скрипта. А он уже при необходимости вызовет Update() всех остальных скриптов. Как известно, если взять 10 000 объектов в сцене и на каждый из них повесить MonoBehaviour, то все они будут помещены во внутренний список. И при каждом Update() движок будет не просто вызывать каждый из 10 000 объектов, но сначала проверять его наличие в сцене. Поэтому архитектура Unity, основанная на компонентной модели и MonoBehaviour, - это зло. А поэтому надо написать свой MVC-подобный велосипед. Думаете, я брежу? Нет, это краткий пересказ проекта с курсов GeekBrains.
Не мог бы ты разобрать код англоязычного ютубера Dani, он также на своем другом канале Danis Tutorials выложил некоторые скрипты в свободный доступ
Разработчики из Майкрософт сидят в Индии 😂
Жду еще по типу разбора, не тока юнити
Сакутин представляет себя богом gamedev
прочитал сначала не «богом», а «багом» 😂
не правда
Sposibo !
Честно, не смотрю канал. Случайно глянул это видео.
Мне не понятно, что значит "стоит перенять 6 вещей"?
Да это же аксиома! Это должно ещё на первом курсе быть железобетонно закреплено в мышлении разработчика.
Может стоит выпускать видео для разных уровней разработчиков? Лучше с пометкой в названии ролика о уровне сложности.
Это видео для тех, кто ещё поля именует, к примеру, не "_counter", а EPSDHSC ))
Я когда узнал, у студента, что это за поле такое, ответ просто убил! )
"EPSDHSC - Эта Переменная Служит Для Хранения Счётчика Цикла"
Рука лицо одним словом. )))
хоть бы оставил ссылку на него...
Сделай третью часть переписки кода ХаудиХо там где разрушение объектов пж
Ты просил 3к лайков уже 4 с хуем
Ура, наконец видос о работе с кодом)
Планируется ли выпускать ролики по книге «элегантные объекты» Егора Бугаенко? Помнится, было на канале тг пару постов, а потом все затихло.
Да, но времени не хватает
4:42 Харош
очень интересно
По поводу Linq. Штука очень полезная. Главное быть с ней очень аккуратным в методах которые часто вызываются во время активного геймплея. Был случай когда к коде происходил поиск подходящего эффекта(префаб с партиклами) при помощи Linq и это давало ощутимую нагрузку. В итоге пришлось заменить поиск на взятие эффекта по ключу из словаря. Вообще словари достаточно быстрая штука и для быстрого сопоставления данный лучше использовать их. По крайней мере так показала моя практика.
Слушай, хотел спросить:у меня есть массив обьектов и словарь этих обьектов. Я в void start пихаю в словарь обьект и имя обьекта.А потом получаю обьект с нужным мне именем. Это же лучше чем каждый раз перебирать массив в цикле?
@@-._63 да, получение элемента из словаря по ключу быстрее линейного перебора. Скорость взятия из словаря O(1), линейным поиском из массива - О(n)
Там под капотом словарь хитро располагает объекты, и быстро их по хэшу достает, если не ошибаюсь
@@voizeh7140 спасибо за ответ
Отличное видео!!! =)
Сними видос про принципы ООП: Solid и Kiss
Забавное различие ) в Котлин sealed жестко регламентирует количество наследников, то есть своего рода расширенный enum. А в С# от sealed class просто нельзя дальше наследоваться? Или можно сделать скажем 3 наследника, а потом уже нельзя будет?
Вообще нельзя наследовать
Если меня кто-то спросит кто такие c# программисты 4:40
Можете написать формулу передвижения по траектории в 2d пространстве, чтобы у объекта всегда была одинаковая скорость(SFML)
Я написал. Использовал формулы из геометрии и векторной алгебры. Берем точку позиции юнита и точку цели, вычисляем расстояние через корень квадрата разницы координат. Затем вычисляем коэффициент изменения каждой координаты юнита. Это его скорость (или длина отрезка на которую от перемещается в каждом кадре) деленная на расстояние до цели. Теперь этот коэффицинет умножаем на величину каждой координаты и значение прибавляем к каждой координате. Готово.
@@Ti0Ti0Kan спс
Immo Landwerth название канала. А вообще хорошо бы ссылку на оригинал.
Харош
Супер
Интересно: Что же этот Человек делает в microsoft, судя по тому, как windows работает это просто редкое исключение из правил
Разраб из майкрософта сидить в VS code на макбуке?)
Когда будет 3й поток на напильник?
А что с книгой? Ну типа я один такой кто не может открыть сайт/?\
final 😎
sealed 💀
Самое забавное это подробный разбор кода других программистов и тичеров, но ни одной толковой вышедшей игры :)
вот именно, просто хватит смотреть всяких инвалидов которые только хотят впарить тебе гов....о курсы
А где видео с крутым разрушением объектов? Под видео с прыжком уже больше 3к лайков...
Здорова я хочу пройти длинный путь для того чтобы эти знания получить и устроиться на работу и пахать как конь чтобы было не меньше 200000
Сделай шрифт побольше,плиз🙏
Сайт на тильде? Можно было и нормальный заказать..
Можно ссылку на оригинал, пожалуйста?
Нашел плейлист кому интересно - th-cam.com/video/wgHIkdUQbp0/w-d-xo.html
Вот блин, как же режет слух эта фраза: обучение с нуля с гарантией трудоустройства. Ну серьезно, не делайте из своих зрителей дураков. Такие вещи гарантировать невозможно в принципе, а тем более на онлайн курсе в несколько месяцев. После скиллбокса и гикбрейнса у нас каждый второй гарантирует трудоустройство, только вот что то я не вижу чтобы у нас все стали айтишниками. Даже если это просто рекламный слоган, то это хреновая идея говорить то чего вы не можете выполнить.
Никто не гарантирует трудоустройство, а мы именно гарантируем, и не словами а договором
Всё очень просто: челы, которые плохо кодят, просто не пройдут курс.
Может красивый код и про мелкософт, но точно не про скорость(
Здорово роман можешь помочь найти программиста для создания игры моих знаний не хватает
О про Кефир сказал что-то
Узнал много интересного, но вот вопрос, если ты не Юнити разработчик, а условно wpf, как ты не из конструктора какие нибудь подписки сделаешь сразу?
ааааа это исследовать элемент
Какой в этом смысл если игры на выходе, говно! Извините за прямоту 😅
Ещё бы кода от профи
Бесстрашный однако, произнес название школы которую нельзя называть!
А эти if else вмесо case?
Ничего не понял но очень интересно.
Линк в апдейте xDD
Ля какой код. Мне срочно надо сушить трусики...
Знаете Рома Вы не патриот буржуйский Код нам палите ,,, они там буржуй Живут, а мы боремся
Что даже не будет токсичной критики? ... дизлайк, отписка!
4:42 давай
привет, проверь код у Гоша дударь
"Linq очень удобная штука". Значит код который мы пишем менее удобный. Раз мы не можем сами написать код который для нас будет хотя бы таким же удобным как linq, то может проблема в нас и в нашем коде?
я до сих по не понял у вас на сайте как петрович то попал к иванычу ахахха а тут такое хд
Нахуя произносить с акцентом таким, если, блт, делаешь это неправильно?
бугаенщина
или нет?
код нормальный, обзор убогий
убогий нормальный, код обзорный
на время интеграции чернеешь.. понятно
х
Ну так дай ссылку на него или имя.
Разве нормально иметь файлы по 200+ строк?
Аналогичный вопрос можно задать относительно количества страниц какой либо книги. В конечном итоге, только читаемость определяет, можно или нет, если код как-то цепляет глаз значит, что-то не так.
Так это идейные наброски, чтобы пока не тратить время на переходы между файлами
Это автор делает для своего удобства, чтобы не бегать по множеству файлов, он сначала построит архитектуру в одном файле, а потом раскидает классы каждый в свой файл
66,6 подписчиков
Последний!
Да не уже ли что-то полезное
Первый
РАСЧЕТ ДАУНОВ ОКОНЧЕН !