2:56 Это как раз пример когда лучше скопировать, чем городить франкенштейн функцию(с). Чтобы избежать дублирования достаточно просто вызвать первую функцию из второй, что тоже плохо, но лучше франкенштейн функции(с).
4:20 - я никогда код не копировал из старых проектов или с интернета, смотрел как он работает, и писал как мне нужно. Максимум копировал что бы запустить у себя локально, потыкать что и как работает, понять как работает, и взять себе это на заметку
3:00 По-моему, здесь "исправленный" пример даже хуже того, что было: дважды повторяется инструкция `return a * b`. Правильно писать так: ``` def multiply_numbers_with_condition(a, b, condition=None): if condition is None or condition(a, b): return a * b return 0 ``` Или можно в одну строчку: ``` def multiply_numbers_with_condition(a, b, condition=None): return a * b if condition is None or condition(a, b) else 0 ```
Тут есть проблема со вторым примером. Да, ты показываешь свою крутось как программист переписав функцию их 4-х строчек в 2. НО! Потом эти сокращенные строчки очень тяжело читать и разбираться что в них происходит. Особенно если тебе нужно во время встречи быстренько зяглянуть в код и расскзать как там бизнес логика работает. Я часто намеренно пишу код как в 1 варианте т.к его проще понимать и поддерживать
@@Сергей-х3в2ь Как в 1-м варианте - имеешь в виду мой первый вариант, а не вариант автора видео? Если так, согласен с тобой только отчасти. Я считаю, что выбор между моими двумя вариантами - дело вкуса. Для меня предпочтительнее второй. Не вижу ничего сложного в операторе if-else, он позволяет писать лаконичный код. Но у каждого свои предпочтения - я потому и привёл два варианта.
Ну одна из хороших практик это комментирование каждой части кода, так порой когда читаешь свой коментарий можешь найти такие моменты которые можно оптимизировать, либо же в будущем можно было легко разобраться за что отвечает та или иная часть кода
Если ты работаешь в комманде, то да, комментировать стоит, мало ли кто там будет просматривать этот код. Но если ты работаешь один или в маленькой команде, то твой код изначально должен комментировать сам себя. Можешь почитать про это и ты поймёшь, что значит "комментировать сам себя".
Комментировать надо только странные решения, объясняя их причину, чтобы не было вопросов на ревью. То есть комментарий должен отвечать не на вопрос "что делает этот код", а на вопрос "почему этот код делает именно так" Все это не касается служебных классов, там надо просто JavaDoc/KDoc комментарий, что этот класс или метод делает. Я конечно говорю про котлин и джаву, но это просто здравый смысл, который применим и в питоне
Совершенно бесполезная активность. Коментарий полезен только в случае WTF-кода, например при какой-то хитрой оптимизации или в удивительной бизнес-логике, реализованной по требованию заказчика.
Если код хорошо написан, ты и так читая его поймешь что он делает. Коментарий нужен либо оставть TODO для правок потом в будущем либо указать какую то важну бизнес логику, и почему сделали этот костыль или еще чего. Комментировать все и вся нет смысла, Единственный пример где это хорошая практика, написание библиотеки которая будет публично использоваться сторонними разработчиками
Код должен быть самодокументируемым. Если код требует комментариев (исключая doc-стринги для документации), то значит код плохо написан. И только в редких случаях какие-то неочевидные моменты должны объясняться в комментариях.
Использование булевских и других флагов, забор из if, функции и методы с простыней кода, игнорирование всего синтаксиса языка (когда на ООП языке пишешь в процедурном стиле), решение простых задач с помощью массивных фреймворков (городить сущности и модель для ОРМ, когда для какого-нибудь отчета достаточно селекта из таблицы)
Пример кода на бидоне прекрасно читается без всяких проблем (я даже не пыхтон программист и прочитал комменты уже после осмысления происходящего), это не спагетти код. Функция структурирована, её цикломатическая сложность низкая, влазит на экран. Для одноразовой утилиты самое то. Как часть более сложного проекта - может быть уже спорно. Кстати, разве в петухоне нет всяких там map'ов? Перекладывать списки через циклы - это стиль, в котором наши отцы писали.
Про лодочный якорь тоже не сказано главного. Чтобы не собирать неиспользуемый код в проекте, достаточно использовать git (или другие системы контроля версия) и правильно им пользоваться. При таком подходе даже комментарии в коде не нужны, т.к. правильно названные и сделанные коммиты будут описывать код, лучше, чем комментарии. Так же при использовании тэгов версий, всегда можно восстановить версию до рефкаторинга и при необходимости проследить вообще все изменения.
С магическими числами не все так однозначно (Не говоря уже про 0 или 1). Главное в написании кода - это что бы было всё понятно, это достигается не только именами для констант. Например нужно перевести км в час в метры в секунду. Для этого можно вынести константу 3.6 и делить на константу. Но лучше сделать функцию, которая просто поделит на 3.6 Т е. Пример: Def kmchToMs(km): return km/3.6 Против const ratioKmchToMs = 3.6 А потом вспоминай что нужно именно делить на эту константу
Да, меня лодочный якорь из спагетти где то валяется. моя первая программа на lua. я там почти все в одну строчку писал, точнее большими абзацами. Не помню правда зачем, то ли думал, что код ускоряю, то ли, что бы запутать потенциального противника... 🤣
Нашел для себя очень крутой способ. Пишите говнокод, или как умеете, но главное чтобы работало так как вы задумали, потом просите чат гпт оптимизировать и улучшить код. Плюс от такого способа в том что можно узнать крутые решения до которых я бы Никогда не додумался. Таким способом в python я научился пользоваться генераторами списков, функцией next например и теперь уже без чата ими пользуюсь, потомучто понял как они работают и зачем нужны
Про изобретение велосипеда, не всегда справедливо, к примеру я по мере необходимости пилю свой фрэймворк для CMSIS STM32 на С. Так вот зачем если есть тот же HAL или arduino? HAL хоть и более простой (на уровне ардуино) но очень не удобный. Arduino хорош для мелких неоптимизированных проектов. А CMSIS позволяет на низком уровне записывая биты в регистры управлять всем. Причем невероятно гибко, проще говоря это ассемблер но с синтаксисом Си. Но беда в том что на CMSIS очень мало библиотек и для настройки пина хотябы как выход нужно слишком много писать кода, а теперь представь себе тебе нужно настроить пины SPI протокола, а так-же передавать и принимать данные по этому низкоуровневому протоколу... С учетом того что CMSIS под каждый процессор и контроллер свой... Приходится изобретать то что делали HAL и разработчики ардуино
Байт на комент зассчитан. В рубрике хардкода никакого хардкода и нет. Все ключи и имена файлов в отдельных переменных. Делайте с ними что хотите, хотите из скрытого хранилища грузите, а хотите из конфиг файла. А вот хардкод это когда ключ прямо в код вставлен. Не через переменную.
вопрос по антипаттерну "изобретение велосипеда", разве чтобы развиваться как разработчик не нужно стараться самостоятельно писать код? типо в чем смысл твоего кода, если ты почти всё взял из чужих кодов/ии/интернета и т.д.
Две крайности. 1. Пишешь простой и понятный код в функциональном стиле на каком-нибудь Haskell 2. Пишешь оптимизированный код который потом будет сложно читать в процедурном стиле на Си Ну да можно попробовать использовать ООП в C++, но часть ресурсов компа будет уходить на создание абстракций классов и объектов. На Си код более оптимальный. Оптимальнее только ассемблер и машинный код.
Никто абсолютно никто, я: в 1 массиве данные для всех переменных, спросите как это работает 🤨 очень просто, создаем массив string и в этот массив записываем абсолютно все данные, вряд ли кто-то сможет взломать программу с 1 переменной ведь она абсолютно везде, из плюсов то что она везде и не надо голову ломать 🤓 также для более уверенности данные в массиве закодировать 128битным ключом шифрования, который для каждого блока когда свой 😂 дальше я еще лучше сделал, так как моя программа умеет передавать данные если код замечат что-то кроме ожидаемых данных, программа со стороны отправителя закрывается 🤗 боже упаси того человека кто попытается взломать мое приложение я же шизик
6:23 да да, конечно, во всем виновата удаленка :D что за бред) по поводу копирования есть другой антипаттерн, его противоположенность - это когда стоило бы сделать копию и на ее основе построить другой блок программы, который логически не связан (выполняет разные бизнес задачи). Но его связывают и так получается связный код, который вообще невозможно поддерживать. Это еще опаснее чем копипаста)
Или делают два продукта с одной кодовой базой и кучей рогаток внутри, потому что "ну это почти одно и то же же" а потом у клиента появляется интерфейс менеджера из-за бага.
На самом деле бывает грешу дубляжом, когда проект уже на проде, и постоянно какие то фичи не нужны, ну простой сайт крч и разве что просит внести какие то правки, новую страницу, то что бы не растягивать и по цене и по времени, бывает грешу этим, выходит быстро и работает, и никак потом в колено себе этим не выстрелю, так как трогать это я больше не буду. Ну и выходит так что сайт выходит в целом чистым и прекрасным, а потом с правками, особенно которые по хорошему заставят переписать пол сайта, что делать конечно никто не будет, прилипает немного говнеца, но в целом как бы норм. Будь это постоянный проект, какое то аля приложение, то там конечно так нельзя, потом страдать будешь
Крайне странным показался листинг кода на третьей минуте видео. Тут начинает страдать нейминг: название функции как будто предполагает, что дополнительное условие должно существовать обязательно. Также функция начинает выполнять две задачи, вместо одной - это нарушает принцип единственной ответственности. Первой задачей становится определить тип умножения: обыкновенное или с добавочным условием, а вторая задача - умножение. Также плохой практикой, по мнению Роберта Мартина, написавшего "Чистый код" и придумавшего SOLID-принципы, считается наложение if/else друг на друга. Если честно, выпади мне доля реализовать алгоритмы умножения двух чисел и умножения двух чисел с условием, то я бы оставил самый первый, доходчивый и легко читаемый, пример. Только бы модифицировал вторую функцию, добавив вызов первой. Тут сложно подобрать оптимальный и единственный вариант решения задачи, поскольку нет полного листинга кода проекта, где используется умножение и умножение с условием.
Ребята, видео очень хорошее, но, пожалуйста. Сделайте звук как раньше, более качественный. А то чувство, что мне диктор в левое ухо говорит только, ещё и небольшой перегруз есть.
Касаемо копирования кода, очень странный аргумент. Копировать код из проекта в проект или из вне, вполне себе стандартная практика. Не, можно конечно писать один и тот же код с нуля, но это бред. Не знаю, как там в ваших питонах, но в нормальных ЯП есть такое понятие, как инкапсуляция. Т.е. если я пишу класс, то его прелесть в том, что могу его использовать и в других проектах, т.к. его логика инкапсулирована. Касаемо первого примера, то в нём строгое нарушение первого принципа solid. Если в названии метода или функции, стоит слово and или or, то лучше её разнести на 2 функции, а в данном случае достаточно вообще убрать функционал кондишена из функции оборачивая её в условие. П.С. Лично я чтобы не копипастить код из проекта в проект, который часто использую создаю небольшие библиотеки. Потому что переиспользование готового проверенного и оттестированного кода, куда целесообразней, чем переписывание своих велосипедов с нуля каждый раз.
Пиши код как знаешь и как тебе нравиться, потому что это только твой проект, и пихуй на все эти антипаттерны. К примеру если писать не на каком то пихтоне, а на c или c++, то там все перечиснные антипаттерны, не имеют смысла. Что с сокрашентем имен переменных, что с копипастом, если у тебя реально большой проект и когда есть способ сократить время для написания какой мини задачи почему бы это не сделать, и да это не делает тебя не опытным программистом. А спагетти код, пхх что если какой то участок кода просто для дебага и временный, который просто нужен чтобы что то проверить, поэтому это вообще бред. И да главный антипатерн - не смотри подобные видео, а учись с книг или же с stack over flow.
Антипаттерн: использовать питухон для прототипирования, используйте JS например. Не надо этот питухон пихать во все дырки. И да питухон это сложный ЯП с кривой норкоманской реализацией. Самый простой ЯП это Lua, из действующих и современных ЯП проще нету.
На питоне прототипы пишут только по двум причинам: его удобно читать ( он похож на псевдокод) и большая часть людей, которые начинают программировать, выбирают именно этот язык.
Копи паст, это же про меня, я в знал что так нельзя делать, но каждый раз говорил потом вытащю на отдельную функцию и так уже у меня проверка данных в бд уже повторяется 3 раза 😄Надо как нибудь все переписать))
@@merionacademy не язви.у тебя в примере про хардкод указаны постоянные - логин,пароль,урл. а потом ты говоришь что если перенести файлы,то всё сломается.какие на хуй файлы? в примере их нет. у тебе ооочень неудачные примеры антишаблонов.короче, ты гавноблогер
Открою секрет новичкам - всё что сказано в видео - мусор. Забудьте и пишите как приходит в голову. Так код проще и понятнее чем когда вы везде впихиваете сраные паттерны. Проблемы которые решают паттерны, по словам автора, почти никогда не случаются. Паттерны для неудачников
Спасибо за ваше мнение, хотя форма его выражения несколько грубовата. Вероятно, вы профессионал в технических навыках, однако стиль коммуникации и уважение к собеседнику в интернет-пространстве многое говорят о человеке. Согласитесь, работая в компании, вы, скорее всего, не стали бы называть труды коллег ‘мусором’. От этого легко сделать вывод, что вы вряд ли являетесь профессионалом, способным давать советы. Тем не менее, оставим это на ваше усмотрение. Рекомендуем лишь подкрепить ваш профессионализм ссылкой на LinkedIn, чтобы люди могли убедиться в вашей компетенции, а не воспринимать ваши слова как нечто несерьёзное.
А ты из тех, которые 15 лет на одном месте свою лапшу пишут или которые каждый год с места на место прыгают, наплевав, как их лапшу потом будут другие поддерживать?
@@mechanism-o4h Вот и пример для новичков. Человек считает что он неспособен написать ничего хорошего не следуя каким то субъективным правилам, которые по его мнению каким то образом должны работать всегда и везде, в любом проекте. Новички, не берите такой пример, думайте сами как всё делать и с практикой станете в разы лучше дурачков которые молятся на паттерны, правила и книги от шарлатанов.
@@ViolentFury1 ты что-то додумываешь того, чего я выше не писал, какой-то разговор самим с собой. Интересно было бы посмотреть, что ты сам создал, чтобы кого-то называть шарлатаном? Какой-то, видимо, всемирно известный проект? Или библиотеку, которой пользуются миллионы программистов по всему миру? А по поводу новичков, в любой крупной компании есть стандарты написания кода, по ним и будешь писать, иначе просто ни одно код-ревью не пройдешь. Независимо от того, что и в каких книгах написано. И если человек планирует какую-то карьеру, то он должен писать так, как понятно другим, а не как ему кажется, что верно, т.к. любой проект это командная работа, а не твой личный стартап. Если хочешь писать так, как нравится, то открывай ИП и велком.
@@mechanism-o4h воооооот, уже ближе к правде насчёт того, что в писать паттерны и прочий мусор придётся потому, что в фирме какой то гений сделал такой стадарт, а не потому, что так писать хорошо. согласен а насчёт всемирно известного проекта, это по твоему критерий "хорошего кода" ? тогда почему всякие фейсбуки переписывали проект после того как стали всемирно известными ? потому, что из-за всех и стандартов кода, код был слишком хорошо и нужно было его слегка попустить ? ;D не понимаю а насчёт того, что код должен быть понятен комманде - так именно если писать как я он будет понятней комманде. пишешь как приходит в голову, смотришь что получается, делаешь код понятным для себя и он будет понятным для других. нет насильно внедрённой необходимости знать всякие паттерны/правила/архитектуры из кучи книг чтобы понять проект. пишешь примитивно и просто и тогда его поймёт даже начинающий программист. а внедрять какие то правила и паттерны из книг - зачем ? что, есть какие то эмпирические доказательства, что все эти правила делают код лучше ?
![[2024/11/13 Лек 10] Основы обработки видео (Влад Шахуро)](http://i.ytimg.com/vi/d5TTtBKtPjI/mqdefault.jpg)
Пройди бесплатный вводный урок нашего продвинутого курса по Python: wiki.merionet.ru/merion-academy/courses/python-advanced-prodvinutyj-kurs/?YT&
2:56 Это как раз пример когда лучше скопировать, чем городить франкенштейн функцию(с). Чтобы избежать дублирования достаточно просто вызвать первую функцию из второй, что тоже плохо, но лучше франкенштейн функции(с).
Тоже удивился этому примеру. Недавна наоборот читал статью о том что так делать не стоит.
по вашему JSON.strungify это функция Франкенштейн?
Ну да, первый принцип SOLID в примере нарушен, это правда.
Лучший стиль программирования это stack over flow программирование
Айда видео про потоки и процессы!
Зачем?
Потоки текут, процессы происходят...
Я пукнул
Я досмотрел, но не удаляйте. Пусть другие тоже посмотрят
4:20 - я никогда код не копировал из старых проектов или с интернета, смотрел как он работает, и писал как мне нужно. Максимум копировал что бы запустить у себя локально, потыкать что и как работает, понять как работает, и взять себе это на заметку
3:00 По-моему, здесь "исправленный" пример даже хуже того, что было: дважды повторяется инструкция `return a * b`. Правильно писать так:
```
def multiply_numbers_with_condition(a, b, condition=None):
if condition is None or condition(a, b):
return a * b
return 0
```
Или можно в одну строчку:
```
def multiply_numbers_with_condition(a, b, condition=None):
return a * b if condition is None or condition(a, b) else 0
```
Ага. Вот так и стоило сделать.
Тут есть проблема со вторым примером.
Да, ты показываешь свою крутось как программист переписав функцию их 4-х строчек в 2. НО!
Потом эти сокращенные строчки очень тяжело читать и разбираться что в них происходит. Особенно если тебе нужно во время встречи быстренько зяглянуть в код и расскзать как там бизнес логика работает.
Я часто намеренно пишу код как в 1 варианте т.к его проще понимать и поддерживать
@@Сергей-х3в2ьну если сложно читать, добавь скобки
@@mrybsminecraft я тут скорее про всякие компактные конструкции говорю
@@Сергей-х3в2ь
Как в 1-м варианте - имеешь в виду мой первый вариант, а не вариант автора видео?
Если так, согласен с тобой только отчасти. Я считаю, что выбор между моими двумя вариантами - дело вкуса. Для меня предпочтительнее второй. Не вижу ничего сложного в операторе if-else, он позволяет писать лаконичный код. Но у каждого свои предпочтения - я потому и привёл два варианта.
Ну одна из хороших практик это комментирование каждой части кода, так порой когда читаешь свой коментарий можешь найти такие моменты которые можно оптимизировать, либо же в будущем можно было легко разобраться за что отвечает та или иная часть кода
Если ты работаешь в комманде, то да, комментировать стоит, мало ли кто там будет просматривать этот код. Но если ты работаешь один или в маленькой команде, то твой код изначально должен комментировать сам себя. Можешь почитать про это и ты поймёшь, что значит "комментировать сам себя".
Комментировать надо только странные решения, объясняя их причину, чтобы не было вопросов на ревью. То есть комментарий должен отвечать не на вопрос "что делает этот код", а на вопрос "почему этот код делает именно так"
Все это не касается служебных классов, там надо просто JavaDoc/KDoc комментарий, что этот класс или метод делает.
Я конечно говорю про котлин и джаву, но это просто здравый смысл, который применим и в питоне
Совершенно бесполезная активность. Коментарий полезен только в случае WTF-кода, например при какой-то хитрой оптимизации или в удивительной бизнес-логике, реализованной по требованию заказчика.
Если код хорошо написан, ты и так читая его поймешь что он делает. Коментарий нужен либо оставть TODO для правок потом в будущем либо указать какую то важну бизнес логику, и почему сделали этот костыль или еще чего. Комментировать все и вся нет смысла, Единственный пример где это хорошая практика, написание библиотеки которая будет публично использоваться сторонними разработчиками
Код должен быть самодокументируемым. Если код требует комментариев (исключая doc-стринги для документации), то значит код плохо написан. И только в редких случаях какие-то неочевидные моменты должны объясняться в комментариях.
Я пишу на языке ассемблера под MS-DOS. Я доволен (пока-что)
Использование булевских и других флагов, забор из if, функции и методы с простыней кода, игнорирование всего синтаксиса языка (когда на ООП языке пишешь в процедурном стиле), решение простых задач с помощью массивных фреймворков (городить сущности и модель для ОРМ, когда для какого-нибудь отчета достаточно селекта из таблицы)
3:01 из одного антипаттерна сделали сразу два. Нужен ранний выход и вынесение флага в отдельный метод.
Не нужно. И нет там флага. Надо проверять по-человечески и всё.
ждём видосы про код ревью)
очень нужная тема
Новый выпуск🎉
Ахахаха, гениальная реклама, в голос посмеялся)
Прес качат
Анжуманя
Бегит
Как всегда интересно и познавательно!
03:00 Молодец - и функции объединил, и копипаст оставил. Сарказм, если непонятно.
классный видос, представляю сколько ушло времени на подбор мемов и монтаж!
Пример кода на бидоне прекрасно читается без всяких проблем (я даже не пыхтон программист и прочитал комменты уже после осмысления происходящего), это не спагетти код. Функция структурирована, её цикломатическая сложность низкая, влазит на экран. Для одноразовой утилиты самое то. Как часть более сложного проекта - может быть уже спорно. Кстати, разве в петухоне нет всяких там map'ов? Перекладывать списки через циклы - это стиль, в котором наши отцы писали.
kstati pod kapotom oni tak i perekladyvayutsya
Про лодочный якорь тоже не сказано главного. Чтобы не собирать неиспользуемый код в проекте, достаточно использовать git (или другие системы контроля версия) и правильно им пользоваться. При таком подходе даже комментарии в коде не нужны, т.к. правильно названные и сделанные коммиты будут описывать код, лучше, чем комментарии. Так же при использовании тэгов версий, всегда можно восстановить версию до рефкаторинга и при необходимости проследить вообще все изменения.
С магическими числами не все так однозначно (Не говоря уже про 0 или 1). Главное в написании кода - это что бы было всё понятно, это достигается не только именами для констант. Например нужно перевести км в час в метры в секунду. Для этого можно вынести константу 3.6 и делить на константу. Но лучше сделать функцию, которая просто поделит на 3.6
Т е. Пример:
Def kmchToMs(km):
return km/3.6
Против
const ratioKmchToMs = 3.6
А потом вспоминай что нужно именно делить на эту константу
Кстати да
2:56 Избавились от дублирования, но добавили флаг, что тоже антипаттерн...
надо было просто во второй функции вызвать первую
1. Нет там флага.
2. Не избавились от дублирования.
7:00 человек с молотком, везде видит гвоздь!
Топ! Все мое на старте собрали 🤠
Начал развивать свой проект, соответственно начал проводить код-ревью.
Очень жду про него ролик, а то ничего не понятно)
Да, меня лодочный якорь из спагетти где то валяется. моя первая программа на lua. я там почти все в одну строчку писал, точнее большими абзацами. Не помню правда зачем, то ли думал, что код ускоряю, то ли, что бы запутать потенциального противника... 🤣
6:42 вместо того чтобы переписывать франкенштейна, можно ему ещё один костыль добавить, а в будущем ещё и ещё и ещё (его же кто то написал уже 😂)
Про Петьку и Василь Ивановича выпал
Пишите код как пишется, а потом смотрите что можно улучшить/убрать. Так гараздо проще чем сразу по правилам писать
спасибо за курсы по норм писанию кода
Многопоточность подавай!!!! Спасибо огромное за контент
5:48
Игроки Factorio: о мама Мия!
Хороший видос!
Ребята вы лучшие !!!
Нашел для себя очень крутой способ.
Пишите говнокод, или как умеете, но главное чтобы работало так как вы задумали, потом просите чат гпт оптимизировать и улучшить код.
Плюс от такого способа в том что можно узнать крутые решения до которых я бы Никогда не додумался.
Таким способом в python я научился пользоваться генераторами списков, функцией next например и теперь уже без чата ими пользуюсь, потомучто понял как они работают и зачем нужны
Жёсткое кодирование мне понадобится после просмотра этого видео
Сделайте видос про Dependency injection (DI)
Лайк за lgtm и номер на тачке
Посмотрел, удаляйте
Прочитал, удаляй
@@xInkognito Понял тебя, удаляйся.
Я понял мир, останавливай матрицу @@Lexxl67
Изгой
хватит так писать, это же глупо и заезженно
6:27 🤣🤣🤣🤣🤣
Про изобретение велосипеда, не всегда справедливо, к примеру я по мере необходимости пилю свой фрэймворк для CMSIS STM32 на С.
Так вот зачем если есть тот же HAL или arduino?
HAL хоть и более простой (на уровне ардуино) но очень не удобный.
Arduino хорош для мелких неоптимизированных проектов.
А CMSIS позволяет на низком уровне записывая биты в регистры управлять всем. Причем невероятно гибко, проще говоря это ассемблер но с синтаксисом Си.
Но беда в том что на CMSIS очень мало библиотек и для настройки пина хотябы как выход нужно слишком много писать кода, а теперь представь себе тебе нужно настроить пины SPI протокола, а так-же передавать и принимать данные по этому низкоуровневому протоколу... С учетом того что CMSIS под каждый процессор и контроллер свой... Приходится изобретать то что делали HAL и разработчики ардуино
Даешь видос про код ревью !
Кайф,спасибо большое
Практики хорошего программирования укороченно будет ПХП. Вам это о чем нибудь говорит ? 01:13
Вы уверены что в вашей аналогии на это сокращение средняя буква - "хорошего" ?
@@ДмитрийКарпич у каждого, своя трактовка ПХП😂
Байт на комент зассчитан. В рубрике хардкода никакого хардкода и нет. Все ключи и имена файлов в отдельных переменных. Делайте с ними что хотите, хотите из скрытого хранилища грузите, а хотите из конфиг файла. А вот хардкод это когда ключ прямо в код вставлен. Не через переменную.
вопрос по антипаттерну "изобретение велосипеда", разве чтобы развиваться как разработчик не нужно стараться самостоятельно писать код? типо в чем смысл твоего кода, если ты почти всё взял из чужих кодов/ии/интернета и т.д.
класс спасибо
Две крайности.
1. Пишешь простой и понятный код в функциональном стиле на каком-нибудь Haskell
2. Пишешь оптимизированный код который потом будет сложно читать в процедурном стиле на Си
Ну да можно попробовать использовать ООП в C++, но часть ресурсов компа будет уходить на создание абстракций классов и объектов. На Си код более оптимальный. Оптимальнее только ассемблер и машинный код.
пиши ооп на си
Можно писать на хаскеле простой и понятный код, который сгенерирует код на мерзком си
Никто абсолютно никто, я: в 1 массиве данные для всех переменных, спросите как это работает 🤨 очень просто, создаем массив string и в этот массив записываем абсолютно все данные, вряд ли кто-то сможет взломать программу с 1 переменной ведь она абсолютно везде, из плюсов то что она везде и не надо голову ломать 🤓 также для более уверенности данные в массиве закодировать 128битным ключом шифрования, который для каждого блока когда свой 😂 дальше я еще лучше сделал, так как моя программа умеет передавать данные если код замечат что-то кроме ожидаемых данных, программа со стороны отправителя закрывается 🤗 боже упаси того человека кто попытается взломать мое приложение я же шизик
6:23 да да, конечно, во всем виновата удаленка :D что за бред)
по поводу копирования есть другой антипаттерн, его противоположенность - это когда стоило бы сделать копию и на ее основе построить другой блок программы, который логически не связан (выполняет разные бизнес задачи). Но его связывают и так получается связный код, который вообще невозможно поддерживать. Это еще опаснее чем копипаста)
Или делают два продукта с одной кодовой базой и кучей рогаток внутри, потому что "ну это почти одно и то же же" а потом у клиента появляется интерфейс менеджера из-за бага.
На самом деле бывает грешу дубляжом, когда проект уже на проде, и постоянно какие то фичи не нужны, ну простой сайт крч и разве что просит внести какие то правки, новую страницу, то что бы не растягивать и по цене и по времени, бывает грешу этим, выходит быстро и работает, и никак потом в колено себе этим не выстрелю, так как трогать это я больше не буду. Ну и выходит так что сайт выходит в целом чистым и прекрасным, а потом с правками, особенно которые по хорошему заставят переписать пол сайта, что делать конечно никто не будет, прилипает немного говнеца, но в целом как бы норм. Будь это постоянный проект, какое то аля приложение, то там конечно так нельзя, потом страдать будешь
Крайне странным показался листинг кода на третьей минуте видео. Тут начинает страдать нейминг: название функции как будто предполагает, что дополнительное условие должно существовать обязательно. Также функция начинает выполнять две задачи, вместо одной - это нарушает принцип единственной ответственности. Первой задачей становится определить тип умножения: обыкновенное или с добавочным условием, а вторая задача - умножение. Также плохой практикой, по мнению Роберта Мартина, написавшего "Чистый код" и придумавшего SOLID-принципы, считается наложение if/else друг на друга. Если честно, выпади мне доля реализовать алгоритмы умножения двух чисел и умножения двух чисел с условием, то я бы оставил самый первый, доходчивый и легко читаемый, пример. Только бы модифицировал вторую функцию, добавив вызов первой.
Тут сложно подобрать оптимальный и единственный вариант решения задачи, поскольку нет полного листинга кода проекта, где используется умножение и умножение с условием.
паттерны со временем становятся антипаттернами
Код должен просто работать, все это фигня, часто вижу что сейчас правильно, но потом будет сложно поддерживать, но идёт поддерживать буду уже не я 😂
Так вот кто создал этих франкенштейнов у меня на проекте 😂
@@Ivan-Shyriaiev да таких много как я много которые в ит не из за того что я кайфую от работы, а просто это простая работа за хорошие деньги
Не досмотрел, не удаляйте пока
Ребята, видео очень хорошее, но, пожалуйста. Сделайте звук как раньше, более качественный. А то чувство, что мне диктор в левое ухо говорит только, ещё и небольшой перегруз есть.
воу, воу. 3:00 - "одна универсальная функция" - это хорошо, а 5:23 - "другая иниверсальная функция" - это нехорошо :) мдааа... определитесь :)
все антипаттерны базируются на нарушении принципов SOLID
Ну и SOLID базируется на специально долгом написании кода😂
3:01 а как решить подобную проблему на си?
Ну, программирование копипастом - это обычная вещь для функционального программирования, поэтому и придумали перегрузки))
А книга про г-код реальна или фотошоп ? Я бы почитал.
Норм )
175-й Haх
1:47 ну я же ем, какое еще говно...
Касаемо копирования кода, очень странный аргумент. Копировать код из проекта в проект или из вне, вполне себе стандартная практика. Не, можно конечно писать один и тот же код с нуля, но это бред. Не знаю, как там в ваших питонах, но в нормальных ЯП есть такое понятие, как инкапсуляция. Т.е. если я пишу класс, то его прелесть в том, что могу его использовать и в других проектах, т.к. его логика инкапсулирована.
Касаемо первого примера, то в нём строгое нарушение первого принципа solid. Если в названии метода или функции, стоит слово and или or, то лучше её разнести на 2 функции, а в данном случае достаточно вообще убрать функционал кондишена из функции оборачивая её в условие.
П.С. Лично я чтобы не копипастить код из проекта в проект, который часто использую создаю небольшие библиотеки. Потому что переиспользование готового проверенного и оттестированного кода, куда целесообразней, чем переписывание своих велосипедов с нуля каждый раз.
Пиши код как знаешь и как тебе нравиться, потому что это только твой проект, и пихуй на все эти антипаттерны. К примеру если писать не на каком то пихтоне, а на c или c++, то там все перечиснные антипаттерны, не имеют смысла. Что с сокрашентем имен переменных, что с копипастом, если у тебя реально большой проект и когда есть способ сократить время для написания какой мини задачи почему бы это не сделать, и да это не делает тебя не опытным программистом. А спагетти код, пхх что если какой то участок кода просто для дебага и временный, который просто нужен чтобы что то проверить, поэтому это вообще бред. И да главный антипатерн - не смотри подобные видео, а учись с книг или же с stack over flow.
Как программист с 10 летним стажем вынесу вердикт этому видео: нормально делай, нормально будет 😂
я говнокодер в восьмилетнем стажем
не согласен! в жс там считаются трактористы )))
Антипаттерн: использовать питухон для прототипирования, используйте JS например. Не надо этот питухон пихать во все дырки. И да питухон это сложный ЯП с кривой норкоманской реализацией. Самый простой ЯП это Lua, из действующих и современных ЯП проще нету.
На питоне прототипы пишут только по двум причинам: его удобно читать ( он похож на псевдокод) и большая часть людей, которые начинают программировать, выбирают именно этот язык.
Лучше всего писать псевдокод
Читайте классику Robert Martin "Clean Code", но сильно не загоняйтесь.
Копи паст, это же про меня, я в знал что так нельзя делать, но каждый раз говорил потом вытащю на отдельную функцию и так уже у меня проверка данных в бд уже повторяется 3 раза 😄Надо как нибудь все переписать))
Если код хороший, его переносят в библиотеку. Так что или подключать библиотеку, либо перепечатывать осознанно - никаких копипастов.
Как-нибудь потом переписать - это сложнее и дольше, чем сразу написать нормально. Такие вещи лучше не оставлять на потом.
@@TuTAH_1у меня не большой проект, я так пару месяцев только разработчик.я думаю впринципе что я чет все не правильно делаю и можно по лучше
64
Автор не разбирается в антипаттернах.
Большое спасибо за вашу подробную, экспертную и тщательно обоснованную аргументацию!
@@merionacademy Внесу чуть больше ясности: ролик гоано.
Как приятно общаться с профессионалами, которые с уважением относятся к собеседнику и четко, аргументированно доносят свои мысли!
@@merionacademy не язви.у тебя в примере про хардкод указаны постоянные - логин,пароль,урл. а потом ты говоришь что если перенести файлы,то всё сломается.какие на хуй файлы? в примере их нет. у тебе ооочень неудачные примеры антишаблонов.короче, ты гавноблогер
Если продолжите ругаться матом, то больше никаких карманных денег не получите 😉
ахаххаахх
Открою секрет новичкам - всё что сказано в видео - мусор.
Забудьте и пишите как приходит в голову. Так код проще и понятнее чем когда вы везде впихиваете сраные паттерны.
Проблемы которые решают паттерны, по словам автора, почти никогда не случаются.
Паттерны для неудачников
Спасибо за ваше мнение, хотя форма его выражения несколько грубовата. Вероятно, вы профессионал в технических навыках, однако стиль коммуникации и уважение к собеседнику в интернет-пространстве многое говорят о человеке. Согласитесь, работая в компании, вы, скорее всего, не стали бы называть труды коллег ‘мусором’. От этого легко сделать вывод, что вы вряд ли являетесь профессионалом, способным давать советы.
Тем не менее, оставим это на ваше усмотрение. Рекомендуем лишь подкрепить ваш профессионализм ссылкой на LinkedIn, чтобы люди могли убедиться в вашей компетенции, а не воспринимать ваши слова как нечто несерьёзное.
А ты из тех, которые 15 лет на одном месте свою лапшу пишут или которые каждый год с места на место прыгают, наплевав, как их лапшу потом будут другие поддерживать?
@@mechanism-o4h Вот и пример для новичков. Человек считает что он неспособен написать ничего хорошего не следуя каким то субъективным правилам, которые по его мнению каким то образом должны работать всегда и везде, в любом проекте.
Новички, не берите такой пример, думайте сами как всё делать и с практикой станете в разы лучше дурачков которые молятся на паттерны, правила и книги от шарлатанов.
@@ViolentFury1 ты что-то додумываешь того, чего я выше не писал, какой-то разговор самим с собой.
Интересно было бы посмотреть, что ты сам создал, чтобы кого-то называть шарлатаном? Какой-то, видимо, всемирно известный проект? Или библиотеку, которой пользуются миллионы программистов по всему миру?
А по поводу новичков, в любой крупной компании есть стандарты написания кода, по ним и будешь писать, иначе просто ни одно код-ревью не пройдешь.
Независимо от того, что и в каких книгах написано. И если человек планирует какую-то карьеру, то он должен писать так, как понятно другим, а не как ему кажется, что верно, т.к. любой проект это командная работа, а не твой личный стартап.
Если хочешь писать так, как нравится, то открывай ИП и велком.
@@mechanism-o4h воооооот, уже ближе к правде насчёт того, что в писать паттерны и прочий мусор придётся потому, что в фирме какой то гений сделал такой стадарт, а не потому, что так писать хорошо. согласен
а насчёт всемирно известного проекта, это по твоему критерий "хорошего кода" ? тогда почему всякие фейсбуки переписывали проект после того как стали всемирно известными ? потому, что из-за всех и стандартов кода, код был слишком хорошо и нужно было его слегка попустить ? ;D не понимаю
а насчёт того, что код должен быть понятен комманде - так именно если писать как я он будет понятней комманде. пишешь как приходит в голову, смотришь что получается, делаешь код понятным для себя и он будет понятным для других. нет насильно внедрённой необходимости знать всякие паттерны/правила/архитектуры из кучи книг чтобы понять проект. пишешь примитивно и просто и тогда его поймёт даже начинающий программист.
а внедрять какие то правила и паттерны из книг - зачем ? что, есть какие то эмпирические доказательства, что все эти правила делают код лучше ?
первый
первый