Правильные методы по Clean Code
Вставка
- Опубліковано 5 чер 2024
- Сегодня мы продолжаем серию лекций по Clean Code. Тема: Как правильно писать методы с точки зрения Clean Code?
Как называть переменные по Clean Code - • Как называть переменны...
Курс о котором говорится в видео: FRONT-END - bit.ly/3r15eMk
00:00 - вступление Сергея Немчинского
00:24 - курс FRONTEND с ментором
01:24 - длина методов
03:40 - метод должен делать что-то одно
04:47 - один уровень абстракции на метод
07:30 - никогда не используйте оператор switch
10:50 - описательные имена
11:50 - аргументы в методах
15:59 - флаги
18:11 - методы не должны иметь сайд эффектов
19:50 - аргументы используемые как результат
21:38 - что-то делаешь или возвращаешь
22:27 - exception или return code
23:55 - DRY (don’t repeat yourself)
24:31 - используйте guard clause
Курсы для новичков:
JAVA - bit.ly/3vDEd58
JAVA Start - bit.ly/3128f4p
PYTHON - bit.ly/3qZWl5J
C# START - bit.ly/3s2ibqu
C#/.NET - bit.ly/3eUWDsi
Инструментарий JAVA - bit.ly/3c1ilZX
Automation QA (Java) - bit.ly/3cQhUkp
ANDROID - bit.ly/3f6nXnJ
WORDPRESS Developer - bit.ly/38X3EVA
SALESFORCE Developer - bit.ly/3tAbZX8
UI/UX дизайн - bit.ly/2P95nA1
GAME DEVELOPMENT - bit.ly/30VFUgi
Обучение на проекте - bit.ly/3bX9acU
Продвинутые курсы для состоявшихся девелоперов:
GRASP and GoF Design patterns - bit.ly/3ttIS7O
Enterprise patterns - bit.ly/30VciQb
Другие услуги:
Пробное собеседование - bit.ly/3r4kZC9
Карьерная консультация - bit.ly/3vG4SOY
Сайт Foxminded: bit.ly/38V9lDt
Foxminded в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
Foxminded в VK: foxminded
Мой Telegram: t.me/nemchinskiyOnBusiness
Для деловых запросов: youtube@foxminded.com.ua
После слов о том, что метод должен умещаться на один экран, я понял, зачем некоторые разработчики используют два монитора, один из которых они поворачивают на 90 градусов.
сломали систему))))
Притом второй монитор ультраширокий)
@@AnrelD и разрешением повыше
И делают шрифт 6го размера)
Да, это сразу бросается в глаза. Экраны разные, шрифты разные... И насчет базовых "10 строк" тоже не все однозначно. Поскольку те же фигурные скобки люди проставляют по-разному. И колбаса типа func().func() тоже начинает смотреться как выход.
Аналогия уровня абстракции с просмотром карты города самое лучшее объяснение того, что такое уровень абстракции.
@@kitten-free биологам, может, и понятнее, но мне больше нравится с картой :)
Обычно когда хочешь разделить метод который делает хорошо 2 вещи, тебе нужно делить не на 2 а на 3 и более методов, так как тебе нужны будут вспомогательные/промежуточные методы и т.д. А потом тебе в голову приходит что эти вспомогательные методы как-то унифицировать, чтобы применять и в других местах и тут начинаешь сидеть и думать, что тебе надо вообще кучу всего рефакторить)
А если изначально писать с таким расчетом, то зачастую все необходимые методы будут уже под рукой)
А если ещё до написания любых методов помнить что один метод должен делать что-то одно, то и рефакторить не придется ;)
Ага, а ещё лучше и вычленять все статические методы из нестатических, с единственной ссылкой на них, можно прям через => перенаправлять, правда методов будет овердохуя, читаться будет как гавно, зато метод в 10 строк...
@@user-qv4hn6qq4n Судя по 10 правилу(21:38 - что-то делаешь или возвращаешь) Python плохой язык. Ибо там есть методы типа list.pop()
@@Drmidon а что этот метод делает?
Как раз досматриваю вашу 2х часовую лекцию по Clean code. Классная подача, спасибо, Сергей 👍
Привет. Спасибо. Очень хочу видео по поводу комитов - что комитить, когда комитить, и какие названия давать, ну и вообще может поглубже разобраться в теме
каждый коммит должен решать только одну задачу. Описание должно кратко, но полно описывать что именно решает этот коммит.
Добавьте примеры, так сказать интерактивности в видео.
Нагляднее будет, если ты сам напишешь говнокод и потом посмотришь это видео
@@kirillamber6056 ага , а если тебе после него прийдется его читать?)))
@@user-mm1xr5to1o легко можно сделать код ревью, даже не понимая с какой предметной областью он работает.
Он и так примеры приводит но устно
@@nabiisakhanov3522 я так понял, что те, кто хорошо разбирается против, чтоб было понятнее тем, кто хуже это умеет?
Очень удобно стало рекламу проматывать - в самом видео Сергей без усов, а в рекламе с усами :D
Спасибо за видео! Даже разрабы с опытом могут подчерпнуть некоторые нюансы!
Лайк за описание что такое уровень абстракции на примере города. Реально топ !
Видео топ! Продолжайте цикл по Clean Code 👍
К сожалению, даже при том, что про клин код говорят на каждом углу, а про значащие имена переменных слышали даже менеджеры по продаже кондитерских изделий, програм аля той, которая рисует искры от волшебной палочки на экране (анклбоб рассказывал про нее в книге), я (думаю, все мы) встречаю очень редко. Обычно это небольшие модули или отдельные файлы\классы, но никогда системы или подсистемы. В большинстве случаев все утыкано методами, называющимися getName (которые, по-хорошему, должны называться getNameOrNullIfUserDoesntExistAndCacheGivenNameAndWriteLogIfNameIsAlreadyCached) и имеющими 300 строк кода после открывающей скобки.
Отличное видео, спасибо. Не заметил как пролетело полчаса, очень полезная инфа, и для новичка почти все понятно было)
Спасибо за отличное видео! Так же хочу сказать, что Вам, Сергей, очень идёт борода без усов. Прям помолодели :D
все программисты, у которых 4к мониторы, расслабились :D
Все программисты у кого микроскопический шрифт тоже расслабились
@@artemartem3375 8 пунктов XD
Особенно те, у кого они развернуты вертикально )
ну программисты с 50-дюймовые экранами тоже расслабились)))
@@kitten-free печально =(((
Топ, это очень интересно и полезно. Спасибо большое)
Сергей, как же вы прекрасны!
Запихнуть код в enum - спасибо док!
Подхвати коллбэк (или его имя) из enum или dict/object или даже array/list/tuple. Просто делегируй
А если несколько типов реакций в разных местах и они разные? Уже не пойдёт.
@@ValentinNechayev я не зря сказал "или его имя". Подхвати метод класса по его имени -- и всё пойдёт
@@kai3341 поподробней плз где там в с#, например, код в enum писать?
@@boevoyhomyachok в шарпах можно положить в enum строку, и метод, соответственно, подхватить по его имени. Но эта история совсем о другом. Не важно, в какой именно контейнер ты положишь коллбэк. Ещё раз читай внимательнее мой комментарий -- я указал контейнеры, частным примером которого является enum. Ещё раз и внимательно -- собери коллбэки в контейнер и делегируй
Благодарю, интересно слушать
Офигенная рубрика. Работаю уже чуть больше года, и часто задумываюсь, а как в той или иной ситуации лучше сделать. И некоторые вопросы прям по полочкам ровно разложили зачем и почему. Видимо пора уже все таки прочитать Роберта Мартина - Clean code и Джошуа Блоха - Effective java )) Спасибо большое за видео, было полезно и интересно!
Большое спасибо! Очень полезная информация.
Отличное видео, спасибо!
Самый главный аргумент против switch в конце, и то в двух словах. Хотелось бы больше узнать про использование полиморфизма вместо switch. Не совсем согласен с тем чтобы поменять switch на if else. Таким образом мы только из одного проблема сделаем другую.
Согласен.
На мой взгляд конструкция switch вполне приемлема в варианте
case one: return One();
case two: return Two();
case three: return Three();
Спасибо за видео!
хорошее видео, хорошая подача. единственное, что хотелось бы хотя бы 1 пример на каждый случай. ждем следующих лекций!
Очень интересно!
Велике дякую вам за це відео.
Круто!
На счет длины методов, Мартин говорил о многословной Java. Если используется какой-либо современный фреймворк (особенно из семейства RoR, Laravel, Django, Sails), то нормальная длина метода будет не более 1-5 строк.
Вообще, когда человек начинает писать тесты не для галочки (работодатель просит), а чтобы действительно снизить возможность возникновения ошибок в коде, он сразу понимает для чего нужен Clean Code и короткие методы в частности.
Гм
populateAssetAndSave() сделаю с него два метода populateAsset() saveAsset() и буду вызывать два метода. и тот метод откуда буду вызвать будет назваться populateAssetAndSave() ?
Ой, плюсую. Очень часто задумываюсь об этом во время работы.
Ну формально, да. Если у тебя, допустим, такая особенная логика, что в свитче где-то по нескольку раз есть populate, где-то Save, а где-то, тоже несколько раз, PopulateAssetSave, то ты обязан объеденить связный вызов.
Вызов нескольких действий одним методом - это регулярная боль.
И ладно если они *всегда* идут толпой, тогда в названии можно оставить более важное действие или придумать какое-то более общее название сему действу. А вот когда они же могут использоваться ещё и по-отдельности, то начинается веселье.
И тут либо держать в голове (что уже плохо), что для конкретных случаев вызываем все три, а в других - вот эти два, либо сделать метод с "неправильным" названием, вызывающий три других метода.
К сожалению,все эти правила не без исключений. Очень часто метод вынужден атомарно делать две, а то и три операции, типа классического CompareAndSwap в многопоточке.
Подписываюсь всеми пятью тентаклями!
9:20 "Не используйте switch" - Pattern Matching in Switch Expressions (C#, Python) не согласны с вами
Thanks!
Супер классные ролики, очень легко заходят, старые лекции тоже интересные, но довольно гружёные, это всё-таки лекции. А так пока едешь на работу самое то и откладывается хорошо.
И побольше по индусов и антипаттерны)) оч. забавно о них слушать
Сергей - это Том Хэнкс мира ИТ.
приятно :) Люблю этого актера
спасибо за пояснение про свитч !!! от всей души :) ..бо, когда смотрел лекции дяди Боба, я так и не понял, на что его заменять и почему
По поводу оператора switch полностью согласен. Можно голову сломать, пока пытаешься понять что человек пытался сделать. А если приходится усложнить немного код, добавить функционала, то приходится полностью его выпиливать, и переписывать на if else
Было бы интересно послушать про clean architecture
Спасибо Сергей за материал. Вопрос: Правильно я понял про switch? Его не использовать только по той причине, что каждое условие требует break? Следовательно, что это к when() не относится, верно?
про enam вместо switch, было полезно спасибо. Да и вообще тема Как помыть кота интересна.
epam?
@@user-zg9ov1oy7z Легкий Митин клитор?))
Насчёт switch я бы поспорил, в контексте языка Go. В нём break работает по-умолчанию, так что лишний раз проваливаться в другую ветку не будет. Ещё особенность, уже языковая: только с помощью него можно проверять тип у какой-нибудь переменной (не касаясь рефлексии)
Насчёт не дублирования кода очень верное замечание, зачем плодить мусор
БОЛЬШЕ ЧИСТОГО КОДА!
Идея крутая, но без примеров «плохо vs хорошо» очень тяжело воспринимать. Ещё круче, если примеры будут не такие как в книге
Позвольте поинтересоваться, а что конкретно из данного видео сложно воспринимается? Примеры вроде банальные.
Мне вот, как не-джаверу, было удивительно узнать, что в enum можно засунуть код - не все языки такое умеют :(
Спасибо большое спасибо большое спасибо большое спасибо большое спасибо большое спасибо большое спасибо большое спасибо большое спасибо 🙏
Маловато внимания уделяется побочным эффектам, производимым методами. Побочные эффекты как мутация полей класса, мутация объектов-параметров, захват локов, и походы в IO необходимо минимизировать как можно сильнее. В идеале переходить к иммутабельным объектам и ФП - чем меньше побочных эффектов, тем более предсказуемее работа функций.
А лучше вообще все переменные сделать ридонли и на каждый чих создавать новый объект вместо изменения старого :)
@@0imax Можно. Если грамотно сделать, тормозить не будет. Читайте про персистентные структуры данных (книга Криса Окасаки и другие источники)
@@linkernick5379 осталось подготовить стопицот тысяч специалистов, способных читать и поддерживать такой код...
Лучше всего сделать нечто вроде универсального Range where T : IComparable.
некоторых языках по сигнатуре метода можно понять, что он и с чем делает, например:
декларация: delete( _ item: Item, withCode deleteCode: Code )
вызов: delete( subSet, withCode: cleanCode )
Спасибо вам, Сергей!
Подскажите котлиновский when ≠ джавовский switch?
Здравствуйте Сергей! На счёт switch-case: Начиная с Java 14, выражение switch имеет дополнительный синтаксис типа Lambda (case ... -> labels), и его можно использовать не только как оператор, но и как выражение, вычисляющее одно значение. В таком случае break не пишется. И это реально очень удобно. Я хоть пока только учусь, но это реально упрощает задачи.
Switch expressions придумали как раз чтобы устранить недостатки обычных свитчей, так что использовать можно и нужно.
если б еще конструкция if else была только выражением, вычисляющим одно значение, то 'это приучило бы разбивать код на небольшие функции-методы
Интересно, вот если был метод, который делал 2-3 действия, мы из него выделили каждое действие в отдельный метод, и потом их по очереди вызвали в первоначальном методе - это будет нормальный код, или калечный? В случае, если эти несколько действий нужно всегда выполнять вместе в строгой очередности - я не вижу нормальной альтернативы. Но и название нормальное придумать в таком случае бывает сложно, ведь это по прежнему метод, вызывающий выполнение нескольких действий...
Вызов нескольких действий одним методом - это регулярная боль.
И ладно если они всегда идут толпой, тогда в названии можно оставить более важное действие или придумать какое-то более общее название сему действу. А вот когда они же могут использоваться ещё и по-отдельности, то начинается веселье.
И тут либо держать в голове (что уже плохо), что для конкретных случаев вызываем все три, а в других - вот эти два, либо сделать метод с "неправильным" названием, вызывающий три других метода.
@Sergey Nemchinskiy switch в языке Swift сделан так что-бы НЕ проваливаться и break писать не нужно. Для Swift можно пересмотреть эту рекомендацию по switch statement?). А если вдруг хотите провалиться - то там вместо break как в других языках, можно написать fallthrough )
Я конечно понимаю, что год прошёл уже)) но.. возможно вы за год уже нашли ответ на этот вопрос?? Как, используете switch??
Всем добрырого времени суток.
Спасибо за полезное видео.
Подскажите как уйти от switch и tapescript.
Также буду благодарен за ссылки где это обьясняется или те или иные технологии используемые для достижения данной задачи!
Позволю себе поспорить про switch'и "в любом си-подобном языке":
1. В некоторых языках break в switch обязателен (например, C#);
2. Есть пример "почти" switch'а -- конструкция when в Kotlin'е, которая, на мой взгляд, лишена почти всех недостатков switch;
3. В некоторых случаях обработку enum'а не перенесёшь внутрь него же -- например, когда он библиотечный.
P.S.: if-else-if-else выглядит тоже скверно
блин теперь новый монитор покупать придется)
буду теперь писать на CleanCodeском языке))
Те, кто писал бизнес-логику на высоком уровне для бинарных деревьев, двусвязных списков - лул.
В методе удаления какого-лиюо элемента со списка будет высокий уровень абстракции и, например в цикле, низкий.
Не, ну можно, конечно, создать подметод для поиска элемента с единственным к ему обращением, ещё можно его статическим пометить ДЛЯ ВЯЗКОСТИ, но это правило к печали будет противоречить правилу методов без параметров, потому что такие методы придётся вызывать с десятью параметрами ref.
Я делаю вывод, что либо эти советы неверные, нелепые, или отсутствует контекст, а именно, когда следует следовать этим правилам, а когда нет.
Один говорит суслику всегда бояться, тот с голоду дохнет, другой - всегда делай, и тот скармливает себя хищнику.
Может, стоит как-то обозначить баланс?
По поводу сокращения методов - ну явно путается причина и следствие.
Ну т.е. вся эта инфа в видео - информационный мусор.
Я огорчён.
Создатели спринга явно не слышали об ограничении в экран )) Та же AutowiredAnnotationBeanPostProcessor, хотя название очень говорящее )
Builder Pattern построен на side effect by definition. Теперь я понял, почему я не люблю этот паттерн - он по определению нарушает конвенцию - имеет side effect и возвращает значение - сам себя.
Конечно для таких тем видео надо не только рассказывать, а приводить примеры скринов экранов с кодом.
Не понял как switch оформить через enum.
В Java можно в enum нафигачить перегруженные методы для каждого значения, и вместо свича просто вызвать метод у енама, который отработает как полиморфизм в зависимости от значения этого енама.
Читай
DZone > Java Zone > Enum Tricks: Featured Enum Instead of Switch
На эту тему есть хорошая книга Макконела «Совершенный код»
Null же многие используют в качестве некой логики, даже в языке есть конструкция ?? типа тернарного для проверки на нулл при присваивании результата
Впечатление, что это java/php-проблемы) Но, думаю, можно применить эти советы даже к python.
Вподобайка і коментар для підтримки каналу!!!!!!!!!!!!
От завжди мізгував над тим якою повинна бути довжина метода. І тут бачу розгорнуту відповідь.
Ще красне дякую за ідею з обджектами, в методі. Часто є такі ситуації.
А стосовно ідеї того що в методі не повинно бути and... Ну власне думав це очевидно. Якщо в тебе є щось дуже складне, логічно розбити код на куски і розбирати його по запчастинам.
Все проблемы со switch и if else if в си-подобных языках произошли и-за того, что if изначально не сделали просто функцией с возвратом значения по условию, это кстати приучило бы кодеров делать лаконичные методы
со всем согласен
ряд тезисов по switch вызвало вопросы, но это уже по другое
Много маленьких методов это тоже плохо, т.к. их можно по ошибке вызвать. Всё-таки функция должна быть жестко связана неразделимой логикой и читаться четко и линейно сверху вниз без вариантов. Тогда функцию легко прочитав держать в голове и понимать что же там было выше
1:45 да и не только надежды и мечты :D
10. Также можно сказать - метод должен быть либо accessor,либо mutator
Цікаво, корисно. Дуже дякую!
// интересно)))
4. Swift С-подобный, при этом свитч там работает нормально, не проваливается и брейк писать не нужно, а если нужно провалится, то есть специальный кейворд. Использования свича всегда проще, быстрее и выглядит лучше, чем большая конструкция ифов.
7. Опять же, в Свифте есть внешнее и внутреннее название аргумента, флаги не страшны если нормально описать что они делают во внешнем названии аргумента функции.
Скажите а эти правила касаються большинтсва языков програмирования? Работаю из С++ и Пайтон. Эти советы применяються к ним?
По switch особенно интересно в свете JEP 361. Половину сказанных проблем убрали. Конструкцию всё больше двигают к паттерн матчингу, так что скорее его использование наоборот возрастет
По поводу того (13:08), что по сигнатуре метода ничего не поймёшь и в него обязательно нужно залезть для того, чтобы понять, как он работает. А имена у параметров для чего?
Имеется ввиду по сигнатуре вызова тип obj.cancel(true, false, 42);
12:00 А какой объект создавать, тоесть какое название классу давать?
Так и скажу на собеседовании, Немчинский запретил юзать switch 😆
он что царь или бог?)))
Немчинскому можно. Он из палеозоя вылез, и до сих пор не в курсе про нормальные ЯП, про pattern matching, и вообще ничего кроме своей джавы не знает. А вот у вас, боюсь, с таким ответом собеседование закончится очень быстро.
Влажные мечты.)
На счет if, elsieif, разве разработчику не придется проверять, не отработают ли другие elseif-ы, перед твоим? Это к вопросу о том, что в случае switch приходится проверять предыдущие условия. Но я не "C-подобный" программист, не могу разделить боль С-шников( У меня switch всегда выполняет только одно условие и выходит без брейков.
Я вот на данный момент разрабатываю псевдографический движок и его модули. Так вот, у меня в модулях и в ядре почти все методы имеют по 5+ аргументов и перегружены в среднем 2-4 раза. Допустим есть метод для вывода текста. Он принимает текст, координаты x, y, две цветовой константы. И что предлагаете?
Сделать объект richText, в нем хранить текст и цвета? Потом сделать vector2 в котором хранить координаты? Лишние объекты получается. Как их инициализировать? Если через конструктор, то та же "проблема" возникает, много аргументов. Еще добавить объект color, который хранит в себе цвета. Если инициализировать через методы, то это тонна кода появится, вместо одной строчки. Ну и зачем мне это?
Избавляться от перегруза смысла нет, так как в коде практически во всех перегрузка есть что-то вроде такого:
mn *func(){
return func(defaultBackground);
}
mn *func(std::string background) {
...
}
Смысла в отдельных функциях нет, будет повторение кода. А повторение кода это плохо, не ради этого делали все эти процедурные парадигмы, объектно ориентированные парадигмы и шаблоны типов.
Считаю то, что вы сказали применимо не во всех случаях и не во всех языках программирования. А иногда если это и применимо, то не меняется ничего от слова совсем
И вот что вам свич не нравится не понятно. Потому что причина о том, что синтаксис стрёмный высосана из пальца. if else писать замучаешься. Это же повторение кода, когда вместо одного значения ты повторяешь целую конструкцию. Да и к тому же если ограничивать длину методов и дробить их, то можно из вида
...
case 9:
result = "fJw";
break;
...
return result;
Можно придти к виду
...
case 9:
return "fJw"
Удобно, не правда ли?
1991-1994г кто-то меня учил, что код подпрограммы должен помещаться на стандартном листе формата А4. В те времена принято было код распечатывать.
Зарисовка тех лет. 1993г. Одесса. СКБ... все разваливается. Бородатый программист маргинального вида подался писать в направлении пенсионного фонда. Остался его начальник, папки с программами. Минивакс в рабочем состоянии. Я остался без непосредственного руководства и сидел изучал Си на IBM 486. Чтобы меня как то загрузить предложили сделать какое то разбиение Фазоманипулированных сигналов ( М последовательностей ) на ортогональные составляющие ( ну или что то такое подобное). Дали книгу про поля Галуа. Дерзай! :-) написал. Решили проверить. Скомпилировали по юниксом мою программы. Минут 15 ушло на изменение кода, чтобы прошло на компиляторе Юникса. ( я писал под Турбо Си Борланла). Потом скриптами написали связь между подпрограммами фильтров М последовательностей. И как бы прогнали задачу вперед-назад. И все сошлось. Это было прикольно. За час где-то из готовых подпрограмм довольно сложная задача была решена. К сожалению красивая идея доктора наук по этим манипуляциям в жизни не сработала. Пытались тогда добить до Парижа. Работали с ними. Но не получилось. Да в общем и французы к нам интерес в то время теряли и мы уже разбегались кто куда.
К стати вот интересно, на счёт возвращения объекта, полученного как параметр, в С++ с этим очень легко: каждый параметр это уже копия, и можно её же и возвращать, главное помнить, что у вас является объектом, например если в качестве параметра выполучили ссылку или если ещё хуже, указатель, и вернуть хотите тоже ссылку, то вы обязаны создать копию того, на что изначальная ссылка указывала и вернуть уже ссылку на копию. Тоже самое и с контейнерами, типа умных указателей.
Рассмешило про маргинальных товарищей которые где-то там сидели.
Работал как то с одним программистом, который в принципе по внешнему виду мог бы наверное быть отнесен к маргинальным товарищам. Борода у него была знатная. Писал он тогда на Си и Клипере. Одно время он работал под юниксом на миниваксе. Это был 1992-1993г. Он все подпрограммы распечатывал на принтере и подшивал в специальные папки со скоросшивателем. Когда он менял код, он заменял листы. Очень все у него было старательно описано и содержалось в порядке. Он любил говорить, что он ни разу в своей жизни не видел настоящего программиста! И в этой шутке была только доля шутки. Зато я с трех лет очень даже видел программиста, настоящего. И большого желания становиться программистом поэтому не имел. Это простыни кода и бессонные ночи. У меня мама математик-программист. Положительное правда тоже в этом было. Бумага в виде рулонов была удобна для устилания полок, а с перфокарт выходили неплохие закладки в книги:-) кстати книги по структурному программированию недавно нашел на полке с книгами про разные Алголы и PL.
По поводу длинного, не читаемого кода. Недавно разглядывал такой шедевр своего хорошего знакомого математика. Несколько файлов в каждом кишка по десятку тысяч строк. Он человек умный и какое то время он даже справлялся с модификацией этого кода. Но через лет 8 после написания и последней модификации этого кода надежды его поднять стали практически нулевыми. И что интересно, там практически нет комментариев. Такой ужас мне бы наверное в страшном сне не приснился:-) бывает...
Ребят, кто-то может пояснить что имеется ввиду на 10:04. Каким образом код можно "вынести в enum"?
Если вы не в курсе языка программирования. на котором пишете, это не Немчинский несет ересь, это вы - недоучка.
enum can contain both concrete methods and abstract methods. If an enum class has an abstract method, then each instance of the enum class must implement it.
Очень полезное видео, ждём про еррор хенддинг.
Подскажите, как намекнуть коллегам почитать Clean Code ?
Некоторые коллеги называют переменные в 1 букву, не пишут никаких комментариев к дикому коду... А мне как новичку сложно читать порой что там они наколбасили
Устраивать дружеские диверсии: присылать ролики по клинкоду, лучше с кликбейтными названиями :)
это жесть...
@@jozakatkin Работали по принципу, ну оно же работает. Как хорошо что я оттуда уволился
Exception или return code. А так же Optional, и другие извращения джентельменов)
Спасибо! Годнота! Мальчика жалко ))
Вопрос не по теме:
Какую бы "сферу" программирования вы посоветовали человеку(мне, школьнику), которому нужен вариант зароботка и минимальный порог вхождения в профессию?
сайты пилить
Верстка с постепенным переходом на реактивный фронтенд (Vue или React)
Все нестатические методы объекта подразумеваются как изменяющие объект. Если метод не изменяет объект, а только производит вычисления с его данными и возвращает результат - этот метод должен быть геттером. Если метод не изменяет _данный_ объект, но имеет прямое отношение к объектам данного класса, он должен быть статическим. Т.е. метод str.toUpper() изменяет регистр внутри самого объекта (возвращает новое значение или нет - не важно), а String::toUpper(str) возвращает копию исходного объекта с измененным регистром, не трогая сам исходный объект.
А если к примеру я использую swing и имею определенный класс с gui в котором есть конструктор с добавлением всех компонентов (предположим это какой-то сложный инетрфейс). И вот проблема - конструктор будет иметь уже не до 10 строк кода, а до 40 и больше) Вопрос: нарушает ли это принципы чистого кода? Если да, то как избежать кроме банальной перефразировки?
В функциональном программировании есть отличный аналог оператору switch - сопоставление с образцом.
в Джаве недавно добавили такой вариант свича
@@user-nz2hh9po2r жду, когда завезут в C++.
1. Часто Switch удобнее и понятнее if-a
2. Метод без параметров - это жесть. Не понятно что и откуда он берет, начинаешь ходить по нему искать какие переменные он использует, какой они имеют тип и откуда они вообще взялись. А еще такой метод приводит к появлению глобальных переменных.
3. Так и не понял, как if в начале метода и закрывающая скобка в конце мешает сделать return посреди метода
К слову о том, что нельзя использовать аргумент как реультат метода и к тому, что изменение состояния объекта должны только void методы. Как тогда реализовывать паттерн строитель? Его методы же как раз и меняют состояние билдера и возвращают ссылку на себя же
switch - отличный олдскульный оператор, то что ему нужен break - это скорее фича. Потому что он как бы проходит и по 1 и по 2 и по 3 блоку, пока не встретит break
По вашей логике можно сказать, что "Не используйте С++, вы можете выстрелить себе в ногу!"
Да, не используйте C++ если вы его не знаете
Про аргументы в методах типа ДатаНачала1, ДатаКонец1, ДатаНачала2, ДатаКонец2... . Как программист на 1С скажу даже более крутую вешь. В 1С есть такая фича, как периодические расчёты, связанные, в основном, с расчётом зарплаты, где учитывается каждый день месяца. Так вот, я видел методы, в которых 31 аргумент вида ЗначениеНа1ЧислоМесяца, ЗначениеНа2ЧислоМесяца и так далее...
А мне вот всегда было интересно насколько красиво делать функции, где меняются параметры, в принципе. Например, можно сделать increment(&a), а можно a=increment(a). Как лучше и в каких ситуациях?
Обычно, очень некрасиво: т.к можно не уследить за изменениями этого a, особенно в языках, где явно не указывается, что это ссылка (привет PHP).
В высокоуровневых языках второй вариант предпочтительнее, первый пошел исторически из с и с++. А в анриал енжине, например, между ними вообще нет разницы, оба варианта интерпретируются движком как возврат значения а.
Свич это нормально, если в нем нет логики, а обычный возврат нужной переменной. Например маппинг Enum - string и тд. С if/else это будет проблематично, ровно как и делить подобный метод
'mkm код лучше перенести в сам enum
Экран можно развернуть по вертикали)
Приветствую всех! Подскажите, пожалуйста, кто в теме - как передать в метод несколько аргументов, с помощью параметра object, как предлагается в видео? Создавал темы на двух форумах, мне рассказывали, но из видео следует, что введение данного параметра должно (по идее) упрощать работу и уменьшать количество кода, а из полученных мною объяснений следует, что это ни разу не проще, количество кода меньше не станет, а наоборот нам ещё понадобится целый класс для этой задачи (возможно, даже не один). Помогите, пожалуйста, разобраться.
Мои коллеги не любят гард клаузы в начале метода, любят, чтоб по индийски было. Рад услышать, что мои предпочтения имеют отношения к нормальным практикам. А то я думал, я странный.