После слов о том, что метод должен умещаться на один экран, я понял, зачем некоторые разработчики используют два монитора, один из которых они поворачивают на 90 градусов.
Да, это сразу бросается в глаза. Экраны разные, шрифты разные... И насчет базовых "10 строк" тоже не все однозначно. Поскольку те же фигурные скобки люди проставляют по-разному. И колбаса типа func().func() тоже начинает смотреться как выход.
Привет. Спасибо. Очень хочу видео по поводу комитов - что комитить, когда комитить, и какие названия давать, ну и вообще может поглубже разобраться в теме
Обычно когда хочешь разделить метод который делает хорошо 2 вещи, тебе нужно делить не на 2 а на 3 и более методов, так как тебе нужны будут вспомогательные/промежуточные методы и т.д. А потом тебе в голову приходит что эти вспомогательные методы как-то унифицировать, чтобы применять и в других местах и тут начинаешь сидеть и думать, что тебе надо вообще кучу всего рефакторить)
Ага, а ещё лучше и вычленять все статические методы из нестатических, с единственной ссылкой на них, можно прям через => перенаправлять, правда методов будет овердохуя, читаться будет как гавно, зато метод в 10 строк...
@@boevoyhomyachok в шарпах можно положить в enum строку, и метод, соответственно, подхватить по его имени. Но эта история совсем о другом. Не важно, в какой именно контейнер ты положишь коллбэк. Ещё раз читай внимательнее мой комментарий -- я указал контейнеры, частным примером которого является enum. Ещё раз и внимательно -- собери коллбэки в контейнер и делегируй
К сожалению, даже при том, что про клин код говорят на каждом углу, а про значащие имена переменных слышали даже менеджеры по продаже кондитерских изделий, програм аля той, которая рисует искры от волшебной палочки на экране (анклбоб рассказывал про нее в книге), я (думаю, все мы) встречаю очень редко. Обычно это небольшие модули или отдельные файлы\классы, но никогда системы или подсистемы. В большинстве случаев все утыкано методами, называющимися getName (которые, по-хорошему, должны называться getNameOrNullIfUserDoesntExistAndCacheGivenNameAndWriteLogIfNameIsAlreadyCached) и имеющими 300 строк кода после открывающей скобки.
Самый главный аргумент против switch в конце, и то в двух словах. Хотелось бы больше узнать про использование полиморфизма вместо switch. Не совсем согласен с тем чтобы поменять switch на if else. Таким образом мы только из одного проблема сделаем другую.
Супер классные ролики, очень легко заходят, старые лекции тоже интересные, но довольно гружёные, это всё-таки лекции. А так пока едешь на работу самое то и откладывается хорошо. И побольше по индусов и антипаттерны)) оч. забавно о них слушать
Офигенная рубрика. Работаю уже чуть больше года, и часто задумываюсь, а как в той или иной ситуации лучше сделать. И некоторые вопросы прям по полочкам ровно разложили зачем и почему. Видимо пора уже все таки прочитать Роберта Мартина - Clean code и Джошуа Блоха - Effective java )) Спасибо большое за видео, было полезно и интересно!
Гм populateAssetAndSave() сделаю с него два метода populateAsset() saveAsset() и буду вызывать два метода. и тот метод откуда буду вызвать будет назваться populateAssetAndSave() ?
Ну формально, да. Если у тебя, допустим, такая особенная логика, что в свитче где-то по нескольку раз есть populate, где-то Save, а где-то, тоже несколько раз, PopulateAssetSave, то ты обязан объеденить связный вызов.
Вызов нескольких действий одним методом - это регулярная боль. И ладно если они *всегда* идут толпой, тогда в названии можно оставить более важное действие или придумать какое-то более общее название сему действу. А вот когда они же могут использоваться ещё и по-отдельности, то начинается веселье. И тут либо держать в голове (что уже плохо), что для конкретных случаев вызываем все три, а в других - вот эти два, либо сделать метод с "неправильным" названием, вызывающий три других метода.
К сожалению,все эти правила не без исключений. Очень часто метод вынужден атомарно делать две, а то и три операции, типа классического CompareAndSwap в многопоточке.
Позвольте поинтересоваться, а что конкретно из данного видео сложно воспринимается? Примеры вроде банальные. Мне вот, как не-джаверу, было удивительно узнать, что в enum можно засунуть код - не все языки такое умеют :(
В Java можно в enum нафигачить перегруженные методы для каждого значения, и вместо свича просто вызвать метод у енама, который отработает как полиморфизм в зависимости от значения этого енама.
Интересно, вот если был метод, который делал 2-3 действия, мы из него выделили каждое действие в отдельный метод, и потом их по очереди вызвали в первоначальном методе - это будет нормальный код, или калечный? В случае, если эти несколько действий нужно всегда выполнять вместе в строгой очередности - я не вижу нормальной альтернативы. Но и название нормальное придумать в таком случае бывает сложно, ведь это по прежнему метод, вызывающий выполнение нескольких действий...
Вызов нескольких действий одним методом - это регулярная боль. И ладно если они всегда идут толпой, тогда в названии можно оставить более важное действие или придумать какое-то более общее название сему действу. А вот когда они же могут использоваться ещё и по-отдельности, то начинается веселье. И тут либо держать в голове (что уже плохо), что для конкретных случаев вызываем все три, а в других - вот эти два, либо сделать метод с "неправильным" названием, вызывающий три других метода.
Маловато внимания уделяется побочным эффектам, производимым методами. Побочные эффекты как мутация полей класса, мутация объектов-параметров, захват локов, и походы в IO необходимо минимизировать как можно сильнее. В идеале переходить к иммутабельным объектам и ФП - чем меньше побочных эффектов, тем более предсказуемее работа функций.
Мои коллеги не любят гард клаузы в начале метода, любят, чтоб по индийски было. Рад услышать, что мои предпочтения имеют отношения к нормальным практикам. А то я думал, я странный.
На счет длины методов, Мартин говорил о многословной Java. Если используется какой-либо современный фреймворк (особенно из семейства RoR, Laravel, Django, Sails), то нормальная длина метода будет не более 1-5 строк. Вообще, когда человек начинает писать тесты не для галочки (работодатель просит), а чтобы действительно снизить возможность возникновения ошибок в коде, он сразу понимает для чего нужен Clean Code и короткие методы в частности.
Те, кто писал бизнес-логику на высоком уровне для бинарных деревьев, двусвязных списков - лул. В методе удаления какого-лиюо элемента со списка будет высокий уровень абстракции и, например в цикле, низкий. Не, ну можно, конечно, создать подметод для поиска элемента с единственным к ему обращением, ещё можно его статическим пометить ДЛЯ ВЯЗКОСТИ, но это правило к печали будет противоречить правилу методов без параметров, потому что такие методы придётся вызывать с десятью параметрами ref. Я делаю вывод, что либо эти советы неверные, нелепые, или отсутствует контекст, а именно, когда следует следовать этим правилам, а когда нет. Один говорит суслику всегда бояться, тот с голоду дохнет, другой - всегда делай, и тот скармливает себя хищнику. Может, стоит как-то обозначить баланс? По поводу сокращения методов - ну явно путается причина и следствие. Ну т.е. вся эта инфа в видео - информационный мусор. Я огорчён.
Я вот на данный момент разрабатываю псевдографический движок и его модули. Так вот, у меня в модулях и в ядре почти все методы имеют по 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'и "в любом си-подобном языке": 1. В некоторых языках break в switch обязателен (например, C#); 2. Есть пример "почти" switch'а -- конструкция when в Kotlin'е, которая, на мой взгляд, лишена почти всех недостатков switch; 3. В некоторых случаях обработку enum'а не перенесёшь внутрь него же -- например, когда он библиотечный. P.S.: if-else-if-else выглядит тоже скверно
По поводу того (13:08), что по сигнатуре метода ничего не поймёшь и в него обязательно нужно залезть для того, чтобы понять, как он работает. А имена у параметров для чего?
Читал Мартина и думал, ну длина метода в 10 строчек - это классно, я за. На практике я часто встречал монстров, но в целом благодаря гигантским мониторам было норм. Но вот сейчас мне приходится работать на 13 дюмовом лаптопе и я резко понял, что 10 строчек - это не красота и чистоплюйство, но это что-то, что может уберечь от нервного срыва и про уровни абстракции сюда же.
@Sergey Nemchinskiy switch в языке Swift сделан так что-бы НЕ проваливаться и break писать не нужно. Для Swift можно пересмотреть эту рекомендацию по switch statement?). А если вдруг хотите провалиться - то там вместо break как в других языках, можно написать fallthrough )
некоторых языках по сигнатуре метода можно понять, что он и с чем делает, например: декларация: delete( _ item: Item, withCode deleteCode: Code ) вызов: delete( subSet, withCode: cleanCode )
Здравствуйте Сергей! На счёт switch-case: Начиная с Java 14, выражение switch имеет дополнительный синтаксис типа Lambda (case ... -> labels), и его можно использовать не только как оператор, но и как выражение, вычисляющее одно значение. В таком случае break не пишется. И это реально очень удобно. Я хоть пока только учусь, но это реально упрощает задачи.
От завжди мізгував над тим якою повинна бути довжина метода. І тут бачу розгорнуту відповідь. Ще красне дякую за ідею з обджектами, в методі. Часто є такі ситуації. А стосовно ідеї того що в методі не повинно бути and... Ну власне думав це очевидно. Якщо в тебе є щось дуже складне, логічно розбити код на куски і розбирати його по запчастинам.
1991-1994г кто-то меня учил, что код подпрограммы должен помещаться на стандартном листе формата А4. В те времена принято было код распечатывать. Зарисовка тех лет. 1993г. Одесса. СКБ... все разваливается. Бородатый программист маргинального вида подался писать в направлении пенсионного фонда. Остался его начальник, папки с программами. Минивакс в рабочем состоянии. Я остался без непосредственного руководства и сидел изучал Си на IBM 486. Чтобы меня как то загрузить предложили сделать какое то разбиение Фазоманипулированных сигналов ( М последовательностей ) на ортогональные составляющие ( ну или что то такое подобное). Дали книгу про поля Галуа. Дерзай! :-) написал. Решили проверить. Скомпилировали по юниксом мою программы. Минут 15 ушло на изменение кода, чтобы прошло на компиляторе Юникса. ( я писал под Турбо Си Борланла). Потом скриптами написали связь между подпрограммами фильтров М последовательностей. И как бы прогнали задачу вперед-назад. И все сошлось. Это было прикольно. За час где-то из готовых подпрограмм довольно сложная задача была решена. К сожалению красивая идея доктора наук по этим манипуляциям в жизни не сработала. Пытались тогда добить до Парижа. Работали с ними. Но не получилось. Да в общем и французы к нам интерес в то время теряли и мы уже разбегались кто куда.
Все нестатические методы объекта подразумеваются как изменяющие объект. Если метод не изменяет объект, а только производит вычисления с его данными и возвращает результат - этот метод должен быть геттером. Если метод не изменяет _данный_ объект, но имеет прямое отношение к объектам данного класса, он должен быть статическим. Т.е. метод str.toUpper() изменяет регистр внутри самого объекта (возвращает новое значение или нет - не важно), а String::toUpper(str) возвращает копию исходного объекта с измененным регистром, не трогая сам исходный объект.
16:19 в целом то всё хорошо и правильно, но есть замечание к самому способу изложения и пояснения проблематики у вас часто и густо звучат фразы типа "ИДЕ помогает", "ИДЕ подсказывает", "ИДЕ за вас ....", и тут же вы 16:19 Тут уж либо ехать либо саночки! Если ваш код редачат через нано или нотпад - то да, аргумент абсолютно валиден. Но если его редачат через нормальную ИДЕ - она покажет какие поля как называются как минимум, а чаще всего и доку по методу, просто при наведении на него п.с. тоже касается и нулов в качестве возвращаемых значений Let the срач begin!
Много маленьких методов это тоже плохо, т.к. их можно по ошибке вызвать. Всё-таки функция должна быть жестко связана неразделимой логикой и читаться четко и линейно сверху вниз без вариантов. Тогда функцию легко прочитав держать в голове и понимать что же там было выше
К слову о том, что нельзя использовать аргумент как реультат метода и к тому, что изменение состояния объекта должны только void методы. Как тогда реализовывать паттерн строитель? Его методы же как раз и меняют состояние билдера и возвращают ссылку на себя же
Про аргументы в методах типа ДатаНачала1, ДатаКонец1, ДатаНачала2, ДатаКонец2... . Как программист на 1С скажу даже более крутую вешь. В 1С есть такая фича, как периодические расчёты, связанные, в основном, с расчётом зарплаты, где учитывается каждый день месяца. Так вот, я видел методы, в которых 31 аргумент вида ЗначениеНа1ЧислоМесяца, ЗначениеНа2ЧислоМесяца и так далее...
4. Swift С-подобный, при этом свитч там работает нормально, не проваливается и брейк писать не нужно, а если нужно провалится, то есть специальный кейворд. Использования свича всегда проще, быстрее и выглядит лучше, чем большая конструкция ифов. 7. Опять же, в Свифте есть внешнее и внутреннее название аргумента, флаги не страшны если нормально описать что они делают во внешнем названии аргумента функции.
К стати вот интересно, на счёт возвращения объекта, полученного как параметр, в С++ с этим очень легко: каждый параметр это уже копия, и можно её же и возвращать, главное помнить, что у вас является объектом, например если в качестве параметра выполучили ссылку или если ещё хуже, указатель, и вернуть хотите тоже ссылку, то вы обязаны создать копию того, на что изначальная ссылка указывала и вернуть уже ссылку на копию. Тоже самое и с контейнерами, типа умных указателей.
Не понял слов, что в 60-70 годы у нас программирования "практически не было" (24:50)? А один только А. П. Ершов чего стоит? К нему же Доня Кнут однозначно с респектом и уважухой относился?
Свич это нормально, если в нем нет логики, а обычный возврат нужной переменной. Например маппинг Enum - string и тд. С if/else это будет проблематично, ровно как и делить подобный метод
По поводу флагов и их наглядности при вызове методов: в C#, если не лениться можно писать имена аргументов. Например: Cancel(paramName1: true, paramName2: false); // не надо объекты городить и всё наглядно.
IDE типа IDEA умеет показывать имена аргументов - это тоже помогает. Но я тут за реформу языков в сторону явных имён в таких случаях (например, Swift позволяет требовать такое - явно назвать определённые аргументы).
А если к примеру я использую swing и имею определенный класс с gui в котором есть конструктор с добавлением всех компонентов (предположим это какой-то сложный инетрфейс). И вот проблема - конструктор будет иметь уже не до 10 строк кода, а до 40 и больше) Вопрос: нарушает ли это принципы чистого кода? Если да, то как избежать кроме банальной перефразировки?
Как то спросил знакомого, проводят ли они объектно ориентированный анализ до программирования. Рисуют ли диаграммы состряний, расписывают жизненные циклы. Товарищ работал в крупной корпорации международной. Капитализация там миллиарды долларов. Он сказал, что пробовали использовать специальное ПО, но получили какую то ерунду и плюнули на это. Интересно с таким подходом какой потом будет код? Будет ли он чистым? Сейчас товарищ в банке крупном работает. Спрашиваю, как там с наследованием и полиморфизмом? Используется? Он сказал, что практически нет. Только когда из библиотек берут что то. Я много лет не занимался программированием. Сейчас к этому возвращаюсь и хотелось бы все делать грамотно, а не лепить кое как на скорую руку. Понятно, что в реальности часто с постановкой задачи проблема и сроки давят. Но все же халтуру лепить не хотелось бы. Лучше тогда наверное и не заниматься этим.
Отличный совет про запрет на манипуляции фронтэнда бэкэндом. Грешу этим и недавно сделал передачу флага в бэк, который должен производить то или иное действие в зависимости от переданного флага. Вместо if else я теперь создам два метода, чтобы исключить эту манипуляцию.
Приветствую всех! Подскажите, пожалуйста, кто в теме - как передать в метод несколько аргументов, с помощью параметра object, как предлагается в видео? Создавал темы на двух форумах, мне рассказывали, но из видео следует, что введение данного параметра должно (по идее) упрощать работу и уменьшать количество кода, а из полученных мною объяснений следует, что это ни разу не проще, количество кода меньше не станет, а наоборот нам ещё понадобится целый класс для этой задачи (возможно, даже не один). Помогите, пожалуйста, разобраться.
На счет if, elsieif, разве разработчику не придется проверять, не отработают ли другие elseif-ы, перед твоим? Это к вопросу о том, что в случае switch приходится проверять предыдущие условия. Но я не "C-подобный" программист, не могу разделить боль С-шников( У меня switch всегда выполняет только одно условие и выходит без брейков.
Это рекомендации, как маску носить))) Вы бы ещё методы по количеству символов ограничили и поставили это ограничение в настройки код ревью, кто превысил, уволить))) Switch отличная конструкция, не надо головой крутить вверх вниз и тем более скролить километры индусячего кода, есть code folding (сворачивание блоков кода) Если ты не поставил break в case или не поставил return, ide с правильно настроенным code linter сообщит об этом)))
вот миллион раз рассказываешь одно и то же, но все равно найдется человек, который ничего не услышит и все равно притащит уже разобранные доводы в тред. Не надо так
Если switch такая уж голимая херня, то почему несколько версий подряд в C# идет активное развитие pattern matching, который по сути есть глубокое развитие синтаксиса switch?
я так понимаю, совет завернуть быший код со switch блоком в enum основывается на возможностях enum именно в джаве (в c++ например enum это тупо набор числовых констант). а как в других яп поступать, может только switch блок выделить в свой метод и назвать вроде OnKind ?
Спасибо Сергей за материал. Вопрос: Правильно я понял про switch? Его не использовать только по той причине, что каждое условие требует break? Следовательно, что это к when() не относится, верно?
Все проблемы со switch и if else if в си-подобных языках произошли и-за того, что if изначально не сделали просто функцией с возвратом значения по условию, это кстати приучило бы кодеров делать лаконичные методы
А мне вот всегда было интересно насколько красиво делать функции, где меняются параметры, в принципе. Например, можно сделать increment(&a), а можно a=increment(a). Как лучше и в каких ситуациях?
В высокоуровневых языках второй вариант предпочтительнее, первый пошел исторически из с и с++. А в анриал енжине, например, между ними вообще нет разницы, оба варианта интерпретируются движком как возврат значения а.
Очень крутой выпуск, про switch прям удивили. Хотя я где то читал что если условие большое то switch быстрее чем куча else if. Но это геймдев и оптимизация кода.
Про бросания исключений везде... вопрос очень спорный. Может быть для java нормально... Хз. Проблема что из клиентского кода может быть не видно тип бросаемого исключения. Тут уже надо лавировать, делать выбор по ситуации.. Мне лично интереснее подход шаблонным классом вида Variant . Но не знаю, можно ли его сделать на джава Бросание исключения видимо надо делать прямо рядом, где вы его ловите. Чтоб красиво прервать функцию. Та самая единая точка выхода)
Наоборот, исключения помогают безболезненно прокинуть ошибку далеко за то место, где она возникла. Конечно, если всё правильно сделано. Например, в текущем коде у меня ошибка может возникнуть на уровне передачи данных между ПК и девайсом, но адекватно отреагировать на эту ошибку можно лишь несколькими вызовами назад - там, где основной алгоритм работает с данными и может нормально прерваться, залогировать ошибку, показать её пользователю и т.д. Согласитесь, было бы странно логирование ошибки и оповещение пользователя о ней размещать в классе, работающим с ком-портом :) Да и прокидывать ошибку через всю цепочку вызовов тоже некрасиво. По сути, получается то же самое поведение, что и с исключениями, только с более загаженным кодом.
Кстати на Хабре этот чистый код разнесли чуть ли не в пух и прах. Рекомендации там в основном хорошие, а вот примеры похоже не очень. Скорее всего это был чей-то чужой код, который Боб подверг рефакторингу. Ну или что то такого рода. И в комментариях рекомендовали книгу Макконела «Совершенный код». Тут тоже ее рекомендуют в коментах.
