После слов о том, что метод должен умещаться на один экран, я понял, зачем некоторые разработчики используют два монитора, один из которых они поворачивают на 90 градусов.

Аналогия уровня абстракции с просмотром карты города самое лучшее объяснение того, что такое уровень абстракции.

Привет. Спасибо. Очень хочу видео по поводу комитов - что комитить, когда комитить, и какие названия давать, ну и вообще может поглубже разобраться в теме

Добавьте примеры, так сказать интерактивности в видео.

Как раз досматриваю вашу 2х часовую лекцию по Clean code. Классная подача, спасибо, Сергей 👍

К сожалению, даже при том, что про клин код говорят на каждом углу, а про значащие имена переменных слышали даже менеджеры по продаже кондитерских изделий, програм аля той, которая рисует искры от волшебной палочки на экране (анклбоб рассказывал про нее в книге), я (думаю, все мы) встречаю очень редко. Обычно это небольшие модули или отдельные файлы\классы, но никогда системы или подсистемы. В большинстве случаев все утыкано методами, называющимися getName (которые, по-хорошему, должны называться getNameOrNullIfUserDoesntExistAndCacheGivenNameAndWriteLogIfNameIsAlreadyCached) и имеющими 300 строк кода после открывающей скобки.

Обычно когда хочешь разделить метод который делает хорошо 2 вещи, тебе нужно делить не на 2 а на 3 и более методов, так как тебе нужны будут вспомогательные/промежуточные методы и т.д. А потом тебе в голову приходит что эти вспомогательные методы как-то унифицировать, чтобы применять и в других местах и тут начинаешь сидеть и думать, что тебе надо вообще кучу всего рефакторить)

Видео топ! Продолжайте цикл по Clean Code 👍

Запихнуть код в enum - спасибо док!

Спасибо за видео! Даже разрабы с опытом могут подчерпнуть некоторые нюансы!

Лайк за описание что такое уровень абстракции на примере города. Реально топ !

Сергей, как же вы прекрасны!

Очень удобно стало рекламу проматывать - в самом видео Сергей без усов, а в рекламе с усами :D

Отличное видео, спасибо. Не заметил как пролетело полчаса, очень полезная инфа, и для новичка почти все понятно было)

Спасибо за отличное видео! Так же хочу сказать, что Вам, Сергей, очень идёт борода без усов. Прям помолодели :D

Самый главный аргумент против switch в конце, и то в двух словах. Хотелось бы больше узнать про использование полиморфизма вместо switch. Не совсем согласен с тем чтобы поменять switch на if else. Таким образом мы только из одного проблема сделаем другую.

Топ, это очень интересно и полезно. Спасибо большое)

Офигенная рубрика. Работаю уже чуть больше года, и часто задумываюсь, а как в той или иной ситуации лучше сделать. И некоторые вопросы прям по полочкам ровно разложили зачем и почему. Видимо пора уже все таки прочитать Роберта Мартина - Clean code и Джошуа Блоха - Effective java )) Спасибо большое за видео, было полезно и интересно!

Благодарю, интересно слушать

Большое спасибо! Очень полезная информация.

Гм populateAssetAndSave() сделаю с него два метода populateAsset() saveAsset() и буду вызывать два метода. и тот метод откуда буду вызвать будет назваться populateAssetAndSave() ?

все программисты, у которых 4к мониторы, расслабились :D

хорошее видео, хорошая подача. единственное, что хотелось бы хотя бы 1 пример на каждый случай. ждем следующих лекций!

Отличное видео, спасибо!

Спасибо за видео!

9:20 "Не используйте switch" - Pattern Matching in Switch Expressions (C#, Python) не согласны с вами

Очень интересно!

Маловато внимания уделяется побочным эффектам, производимым методами. Побочные эффекты как мутация полей класса, мутация объектов-параметров, захват локов, и походы в IO необходимо минимизировать как можно сильнее. В идеале переходить к иммутабельным объектам и ФП - чем меньше побочных эффектов, тем более предсказуемее работа функций.

Велике дякую вам за це відео.

Подписываюсь всеми пятью тентаклями!

На счет длины методов, Мартин говорил о многословной Java. Если используется какой-либо современный фреймворк (особенно из семейства RoR, Laravel, Django, Sails), то нормальная длина метода будет не более 1-5 строк. Вообще, когда человек начинает писать тесты не для галочки (работодатель просит), а чтобы действительно снизить возможность возникновения ошибок в коде, он сразу понимает для чего нужен Clean Code и короткие методы в частности.

Круто!

Спасибо большое спасибо большое спасибо большое спасибо большое спасибо большое спасибо большое спасибо большое спасибо большое спасибо 🙏

Было бы интересно послушать про clean architecture

про enam вместо switch, было полезно спасибо. Да и вообще тема Как помыть кота интересна.

спасибо за пояснение про свитч !!! от всей души :) ..бо, когда смотрел лекции дяди Боба, я так и не понял, на что его заменять и почему

Насчёт switch я бы поспорил, в контексте языка Go. В нём break работает по-умолчанию, так что лишний раз проваливаться в другую ветку не будет. Ещё особенность, уже языковая: только с помощью него можно проверять тип у какой-нибудь переменной (не касаясь рефлексии)

Здравствуйте Сергей! На счёт switch-case: Начиная с Java 14, выражение switch имеет дополнительный синтаксис типа Lambda (case ... -> labels), и его можно использовать не только как оператор, но и как выражение, вычисляющее одно значение. В таком случае break не пишется. И это реально очень удобно. Я хоть пока только учусь, но это реально упрощает задачи.

Насчёт не дублирования кода очень верное замечание, зачем плодить мусор

Лучше всего сделать нечто вроде универсального Range where T : IComparable.

По поводу оператора switch полностью согласен. Можно голову сломать, пока пытаешься понять что человек пытался сделать. А если приходится усложнить немного код, добавить функционала, то приходится полностью его выпиливать, и переписывать на if else

Thanks!

Те, кто писал бизнес-логику на высоком уровне для бинарных деревьев, двусвязных списков - лул. В методе удаления какого-лиюо элемента со списка будет высокий уровень абстракции и, например в цикле, низкий. Не, ну можно, конечно, создать подметод для поиска элемента с единственным к ему обращением, ещё можно его статическим пометить ДЛЯ ВЯЗКОСТИ, но это правило к печали будет противоречить правилу методов без параметров, потому что такие методы придётся вызывать с десятью параметрами ref. Я делаю вывод, что либо эти советы неверные, нелепые, или отсутствует контекст, а именно, когда следует следовать этим правилам, а когда нет. Один говорит суслику всегда бояться, тот с голоду дохнет, другой - всегда делай, и тот скармливает себя хищнику. Может, стоит как-то обозначить баланс? По поводу сокращения методов - ну явно путается причина и следствие. Ну т.е. вся эта инфа в видео - информационный мусор. Я огорчён.

Позволю себе поспорить про switch'и "в любом си-подобном языке": 1. В некоторых языках break в switch обязателен (например, C#); 2. Есть пример "почти" switch'а -- конструкция when в Kotlin'е, которая, на мой взгляд, лишена почти всех недостатков switch; 3. В некоторых случаях обработку enum'а не перенесёшь внутрь него же -- например, когда он библиотечный. P.S.: if-else-if-else выглядит тоже скверно

От завжди мізгував над тим якою повинна бути довжина метода. І тут бачу розгорнуту відповідь. Ще красне дякую за ідею з обджектами, в методі. Часто є такі ситуації. А стосовно ідеї того що в методі не повинно бути and... Ну власне думав це очевидно. Якщо в тебе є щось дуже складне, логічно розбити код на куски і розбирати його по запчастинам.

БОЛЬШЕ ЧИСТОГО КОДА!

@Sergey Nemchinskiy switch в языке Swift сделан так что-бы НЕ проваливаться и break писать не нужно. Для Swift можно пересмотреть эту рекомендацию по switch statement?). А если вдруг хотите провалиться - то там вместо break как в других языках, можно написать fallthrough )

некоторых языках по сигнатуре метода можно понять, что он и с чем делает, например: декларация: delete( _ item: Item, withCode deleteCode: Code ) вызов: delete( subSet, withCode: cleanCode )

Интересно, вот если был метод, который делал 2-3 действия, мы из него выделили каждое действие в отдельный метод, и потом их по очереди вызвали в первоначальном методе - это будет нормальный код, или калечный? В случае, если эти несколько действий нужно всегда выполнять вместе в строгой очередности - я не вижу нормальной альтернативы. Но и название нормальное придумать в таком случае бывает сложно, ведь это по прежнему метод, вызывающий выполнение нескольких действий...

Спасибо вам, Сергей! Подскажите котлиновский when ≠ джавовский switch?

Спасибо Сергей за материал. Вопрос: Правильно я понял про switch? Его не использовать только по той причине, что каждое условие требует break? Следовательно, что это к when() не относится, верно?

Я вот на данный момент разрабатываю псевдографический движок и его модули. Так вот, у меня в модулях и в ядре почти все методы имеют по 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" Удобно, не правда ли?

Супер классные ролики, очень легко заходят, старые лекции тоже интересные, но довольно гружёные, это всё-таки лекции. А так пока едешь на работу самое то и откладывается хорошо. И побольше по индусов и антипаттерны)) оч. забавно о них слушать

Всем добрырого времени суток. Спасибо за полезное видео. Подскажите как уйти от switch и tapescript. Также буду благодарен за ссылки где это обьясняется или те или иные технологии используемые для достижения данной задачи!

Много маленьких методов это тоже плохо, т.к. их можно по ошибке вызвать. Всё-таки функция должна быть жестко связана неразделимой логикой и читаться четко и линейно сверху вниз без вариантов. Тогда функцию легко прочитав держать в голове и понимать что же там было выше

буду теперь писать на CleanCodeском языке))

На эту тему есть хорошая книга Макконела «Совершенный код»

блин теперь новый монитор покупать придется)

Цікаво, корисно. Дуже дякую!

Сергей - это Том Хэнкс мира ИТ.

Скажите а эти правила касаються большинтсва языков програмирования? Работаю из С++ и Пайтон. Эти советы применяються к ним?

4. Swift С-подобный, при этом свитч там работает нормально, не проваливается и брейк писать не нужно, а если нужно провалится, то есть специальный кейворд. Использования свича всегда проще, быстрее и выглядит лучше, чем большая конструкция ифов. 7. Опять же, в Свифте есть внешнее и внутреннее название аргумента, флаги не страшны если нормально описать что они делают во внешнем названии аргумента функции.

Null же многие используют в качестве некой логики, даже в языке есть конструкция ?? типа тернарного для проверки на нулл при присваивании результата

12:00 А какой объект создавать, тоесть какое название классу давать?

Builder Pattern построен на side effect by definition. Теперь я понял, почему я не люблю этот паттерн - он по определению нарушает конвенцию - имеет side effect и возвращает значение - сам себя.

Создатели спринга явно не слышали об ограничении в экран )) Та же AutowiredAnnotationBeanPostProcessor, хотя название очень говорящее )

Конечно для таких тем видео надо не только рассказывать, а приводить примеры скринов экранов с кодом. Не понял как switch оформить через enum.

со всем согласен ряд тезисов по switch вызвало вопросы, но это уже по другое

Все нестатические методы объекта подразумеваются как изменяющие объект. Если метод не изменяет объект, а только производит вычисления с его данными и возвращает результат - этот метод должен быть геттером. Если метод не изменяет _данный_ объект, но имеет прямое отношение к объектам данного класса, он должен быть статическим. Т.е. метод str.toUpper() изменяет регистр внутри самого объекта (возвращает новое значение или нет - не важно), а String::toUpper(str) возвращает копию исходного объекта с измененным регистром, не трогая сам исходный объект.

Вподобайка і коментар для підтримки каналу!!!!!!!!!!!!

Впечатление, что это java/php-проблемы) Но, думаю, можно применить эти советы даже к python.

Идея крутая, но без примеров «плохо vs хорошо» очень тяжело воспринимать. Ещё круче, если примеры будут не такие как в книге

C guard clause я с начала нуливых на пхп так делать начал, сам интуитивно пришел. а вот с exception вместо return както не понятно, почему так надо делать?

Все проблемы со switch и if else if в си-подобных языках произошли и-за того, что if изначально не сделали просто функцией с возвратом значения по условию, это кстати приучило бы кодеров делать лаконичные методы

В функциональном программировании есть отличный аналог оператору switch - сопоставление с образцом.

На счет if, elsieif, разве разработчику не придется проверять, не отработают ли другие elseif-ы, перед твоим? Это к вопросу о том, что в случае switch приходится проверять предыдущие условия. Но я не "C-подобный" программист, не могу разделить боль С-шников( У меня switch всегда выполняет только одно условие и выходит без брейков.

10. Также можно сказать - метод должен быть либо accessor,либо mutator

1991-1994г кто-то меня учил, что код подпрограммы должен помещаться на стандартном листе формата А4. В те времена принято было код распечатывать. Зарисовка тех лет. 1993г. Одесса. СКБ... все разваливается. Бородатый программист маргинального вида подался писать в направлении пенсионного фонда. Остался его начальник, папки с программами. Минивакс в рабочем состоянии. Я остался без непосредственного руководства и сидел изучал Си на IBM 486. Чтобы меня как то загрузить предложили сделать какое то разбиение Фазоманипулированных сигналов ( М последовательностей ) на ортогональные составляющие ( ну или что то такое подобное). Дали книгу про поля Галуа. Дерзай! :-) написал. Решили проверить. Скомпилировали по юниксом мою программы. Минут 15 ушло на изменение кода, чтобы прошло на компиляторе Юникса. ( я писал под Турбо Си Борланла). Потом скриптами написали связь между подпрограммами фильтров М последовательностей. И как бы прогнали задачу вперед-назад. И все сошлось. Это было прикольно. За час где-то из готовых подпрограмм довольно сложная задача была решена. К сожалению красивая идея доктора наук по этим манипуляциям в жизни не сработала. Пытались тогда добить до Парижа. Работали с ними. Но не получилось. Да в общем и французы к нам интерес в то время теряли и мы уже разбегались кто куда.

По поводу того (13:08), что по сигнатуре метода ничего не поймёшь и в него обязательно нужно залезть для того, чтобы понять, как он работает. А имена у параметров для чего?

Рассмешило про маргинальных товарищей которые где-то там сидели. Работал как то с одним программистом, который в принципе по внешнему виду мог бы наверное быть отнесен к маргинальным товарищам. Борода у него была знатная. Писал он тогда на Си и Клипере. Одно время он работал под юниксом на миниваксе. Это был 1992-1993г. Он все подпрограммы распечатывал на принтере и подшивал в специальные папки со скоросшивателем. Когда он менял код, он заменял листы. Очень все у него было старательно описано и содержалось в порядке. Он любил говорить, что он ни разу в своей жизни не видел настоящего программиста! И в этой шутке была только доля шутки. Зато я с трех лет очень даже видел программиста, настоящего. И большого желания становиться программистом поэтому не имел. Это простыни кода и бессонные ночи. У меня мама математик-программист. Положительное правда тоже в этом было. Бумага в виде рулонов была удобна для устилания полок, а с перфокарт выходили неплохие закладки в книги:-) кстати книги по структурному программированию недавно нашел на полке с книгами про разные Алголы и PL. По поводу длинного, не читаемого кода. Недавно разглядывал такой шедевр своего хорошего знакомого математика. Несколько файлов в каждом кишка по десятку тысяч строк. Он человек умный и какое то время он даже справлялся с модификацией этого кода. Но через лет 8 после написания и последней модификации этого кода надежды его поднять стали практически нулевыми. И что интересно, там практически нет комментариев. Такой ужас мне бы наверное в страшном сне не приснился:-) бывает...

switch - отличный олдскульный оператор, то что ему нужен break - это скорее фича. Потому что он как бы проходит и по 1 и по 2 и по 3 блоку, пока не встретит break По вашей логике можно сказать, что "Не используйте С++, вы можете выстрелить себе в ногу!" Да, не используйте C++ если вы его не знаете

Это рекомендации, как маску носить))) Вы бы ещё методы по количеству символов ограничили и поставили это ограничение в настройки код ревью, кто превысил, уволить))) Switch отличная конструкция, не надо головой крутить вверх вниз и тем более скролить километры индусячего кода, есть code folding (сворачивание блоков кода) Если ты не поставил break в case или не поставил return, ide с правильно настроенным code linter сообщит об этом)))

По поводу флагов и их наглядности при вызове методов: в C#, если не лениться можно писать имена аргументов. Например: Cancel(paramName1: true, paramName2: false); // не надо объекты городить и всё наглядно.

1:45 да и не только надежды и мечты :D

А если к примеру я использую swing и имею определенный класс с gui в котором есть конструктор с добавлением всех компонентов (предположим это какой-то сложный инетрфейс). И вот проблема - конструктор будет иметь уже не до 10 строк кода, а до 40 и больше) Вопрос: нарушает ли это принципы чистого кода? Если да, то как избежать кроме банальной перефразировки?

я так понимаю, совет завернуть быший код со switch блоком в enum основывается на возможностях enum именно в джаве (в c++ например enum это тупо набор числовых констант). а как в других яп поступать, может только switch блок выделить в свой метод и назвать вроде OnKind ?

По switch особенно интересно в свете JEP 361. Половину сказанных проблем убрали. Конструкцию всё больше двигают к паттерн матчингу, так что скорее его использование наоборот возрастет

Ребят, кто-то может пояснить что имеется ввиду на 10:04. Каким образом код можно "вынести в enum"?

1. Часто Switch удобнее и понятнее if-a 2. Метод без параметров - это жесть. Не понятно что и откуда он берет, начинаешь ходить по нему искать какие переменные он использует, какой они имеют тип и откуда они вообще взялись. А еще такой метод приводит к появлению глобальных переменных. 3. Так и не понял, как if в начале метода и закрывающая скобка в конце мешает сделать return посреди метода

Про аргументы в методах типа ДатаНачала1, ДатаКонец1, ДатаНачала2, ДатаКонец2... . Как программист на 1С скажу даже более крутую вешь. В 1С есть такая фича, как периодические расчёты, связанные, в основном, с расчётом зарплаты, где учитывается каждый день месяца. Так вот, я видел методы, в которых 31 аргумент вида ЗначениеНа1ЧислоМесяца, ЗначениеНа2ЧислоМесяца и так далее...

Я про enum не понял. 10:00 Мне нужно выносить такие вещи в отдельный класс, массив?

Очень полезное видео, ждём про еррор хенддинг. Подскажите, как намекнуть коллегам почитать Clean Code ? Некоторые коллеги называют переменные в 1 букву, не пишут никаких комментариев к дикому коду... А мне как новичку сложно читать порой что там они наколбасили

Так и скажу на собеседовании, Немчинский запретил юзать switch 😆

длина метода зависит от решаемой им задачи. и разбивать решение на много методов редко поможет решению задачи.. Если задачки простенькие то да. Но читать код состоящий из названий методов совсем неудобно. После того как метод написан можно его оптимизировать и унифицировать, но для других это вряд ли упростит его чтение. А так в принципе любая хорошая программ занимает не более 10 строк. Но понять ее практически невозможно.

Ну работа с enum через switch удобнее, но то ладно - вкусовщина. Вот switch оператор затронули, а что на счёт switch expression?

К стати вот интересно, на счёт возвращения объекта, полученного как параметр, в С++ с этим очень легко: каждый параметр это уже копия, и можно её же и возвращать, главное помнить, что у вас является объектом, например если в качестве параметра выполучили ссылку или если ещё хуже, указатель, и вернуть хотите тоже ссылку, то вы обязаны создать копию того, на что изначальная ссылка указывала и вернуть уже ссылку на копию. Тоже самое и с контейнерами, типа умных указателей.

К слову о том, что нельзя использовать аргумент как реультат метода и к тому, что изменение состояния объекта должны только void методы. Как тогда реализовывать паттерн строитель? Его методы же как раз и меняют состояние билдера и возвращают ссылку на себя же

Exception или return code. А так же Optional, и другие извращения джентельменов)

Экран можно развернуть по вертикали)

Приветствую всех! Подскажите, пожалуйста, кто в теме - как передать в метод несколько аргументов, с помощью параметра object, как предлагается в видео? Создавал темы на двух форумах, мне рассказывали, но из видео следует, что введение данного параметра должно (по идее) упрощать работу и уменьшать количество кода, а из полученных мною объяснений следует, что это ни разу не проще, количество кода меньше не станет, а наоборот нам ещё понадобится целый класс для этой задачи (возможно, даже не один). Помогите, пожалуйста, разобраться.