Правильные методы по Clean Code

[@SergeyNemchinskiy]

💪Новый поток advanced тренинга Enterprise patterns стартует 2.12 - go.foxminded.ua/400yNTl

[@enkryp]

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

[@maxlich9139]

сломали систему))))

[@AnrelD]

Притом второй монитор ультраширокий)

[@trofimchikchik]

@@AnrelD и разрешением повыше

[@forty_se7en]

И делают шрифт 6го размера)

[@alexperemey6046]

Да, это сразу бросается в глаза. Экраны разные, шрифты разные... И насчет базовых "10 строк" тоже не все однозначно. Поскольку те же фигурные скобки люди проставляют по-разному. И колбаса типа func().func() тоже начинает смотреться как выход.

[@ansarozden5767]

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

[@0imax]

@@kitten-free биологам, может, и понятнее, но мне больше нравится с картой :)

[@max_mgtow]

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

[@michaeldeyev8809]

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

[@MgsMen]

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

[@pranatank4965]

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

[@niknikagain]

каждый коммит должен решать только одну задачу. Описание должно кратко, но полно описывать что именно решает этот коммит.

[@Serhio_Murini]

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

[@playerkilleryakutia9415]

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

[@userlink-12]

А если изначально писать с таким расчетом, то зачастую все необходимые методы будут уже под рукой)

[@undefined-n5v]

А если ещё до написания любых методов помнить что один метод должен делать что-то одно, то и рефакторить не придется ;)

[@VladisS.Vostok2000]

Ага, а ещё лучше и вычленять все статические методы из нестатических, с единственной ссылкой на них, можно прям через => перенаправлять, правда методов будет овердохуя, читаться будет как гавно, зато метод в 10 строк...

[@Drmidon]

@@undefined-n5v Судя по 10 правилу(21:38​ - что-то делаешь или возвращаешь) Python плохой язык. Ибо там есть методы типа list.pop()

[@maxlich9139]

@@Drmidon а что этот метод делает?

[@yankilo]

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

[@jollyroger2757]

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

[@kirillamber6056]

Нагляднее будет, если ты сам напишешь говнокод и потом посмотришь это видео

[@Sprint-n3n]

@@kirillamber6056 ага , а если тебе после него прийдется его читать?)))

[@kirillamber6056]

@@Sprint-n3n легко можно сделать код ревью, даже не понимая с какой предметной областью он работает.

[@nabiisakhanov3522]

Он и так примеры приводит но устно

[@Sprint-n3n]

@@nabiisakhanov3522 я так понял, что те, кто хорошо разбирается против, чтоб было понятнее тем, кто хуже это умеет?

[@ЕрвандАгаджанян-в3к]

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

[@alexxx4434]

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

[@kai3341]

Подхвати коллбэк (или его имя) из enum или dict/object или даже array/list/tuple. Просто делегируй

[@ValentinNechayev]

А если несколько типов реакций в разных местах и они разные? Уже не пойдёт.

[@kai3341]

@@ValentinNechayev я не зря сказал "или его имя". Подхвати метод класса по его имени -- и всё пойдёт

[@boevoyhomyachok]

@@kai3341 поподробней плз где там в с#, например, код в enum писать?

[@kai3341]

@@boevoyhomyachok в шарпах можно положить в enum строку, и метод, соответственно, подхватить по его имени. Но эта история совсем о другом. Не важно, в какой именно контейнер ты положишь коллбэк. Ещё раз читай внимательнее мой комментарий -- я указал контейнеры, частным примером которого является enum. Ещё раз и внимательно -- собери коллбэки в контейнер и делегируй

[@doopath8737]

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

[@KillerCourse]

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

[@samdistortion7588]

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

[@Enthusiast91]

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

[@vahekhachaturian2424]

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

[@АлександрНевельский-л2з]

Согласен. На мой взгляд конструкция switch вполне приемлема в варианте case one: return One(); case two: return Two(); case three: return Three();

[@PianoElipse]

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

[@artemartem3375]

Все программисты у кого микроскопический шрифт тоже расслабились

[@PianoElipse]

@@artemartem3375 8 пунктов XD

[@demiurgen13]

Особенно те, у кого они развернуты вертикально )

[@maxlich9139]

ну программисты с 50-дюймовые экранами тоже расслабились)))

[@maxlich9139]

@@kitten-free печально =(((

[@peterswinoff1886]

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

[@persoloid]

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

[@ЯківСинявський]

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

[@swan-bird]

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

[@Alex11Fox]

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

[@ДмитрийВладимирович-т7ж]

epam?

[@KaputTV]

@@ДмитрийВладимирович-т7ж Легкий Митин клитор?))

[@ДональдТрамп-м1г]

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

[@sviatoslavhavrylo8580]

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

[@fallenangel1395]

Ой, плюсую. Очень часто задумываюсь об этом во время работы.

[@VladisS.Vostok2000]

Ну формально, да. Если у тебя, допустим, такая особенная логика, что в свитче где-то по нескольку раз есть populate, где-то Save, а где-то, тоже несколько раз, PopulateAssetSave, то ты обязан объеденить связный вызов.

[@0imax]

Вызов нескольких действий одним методом - это регулярная боль. И ладно если они *всегда* идут толпой, тогда в названии можно оставить более важное действие или придумать какое-то более общее название сему действу. А вот когда они же могут использоваться ещё и по-отдельности, то начинается веселье. И тут либо держать в голове (что уже плохо), что для конкретных случаев вызываем все три, а в других - вот эти два, либо сделать метод с "неправильным" названием, вызывающий три других метода.

[@cheefoxcheefox2372]

К сожалению,все эти правила не без исключений. Очень часто метод вынужден атомарно делать две, а то и три операции, типа классического CompareAndSwap в многопоточке.

[@alexeymezenin]

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

[@ShargTV]

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

[@RUMACTEP]

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

[@ГеоргВартанов]

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

[@romantsyupryk3009]

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

[@linkernick5379]

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

[@0imax]

А лучше вообще все переменные сделать ридонли и на каждый чих создавать новый объект вместо изменения старого :)

[@linkernick5379]

@@0imax Можно. Если грамотно сделать, тормозить не будет. Читайте про персистентные структуры данных (книга Криса Окасаки и другие источники)

[@0imax]

@@linkernick5379 осталось подготовить стопицот тысяч специалистов, способных читать и поддерживать такой код...

[@artursveshnikov7668]

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

[@mrybs]

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

[@progressive_agriculture]

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

[@jamalzeynalov2196]

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

[@0imax]

Позвольте поинтересоваться, а что конкретно из данного видео сложно воспринимается? Примеры вроде банальные. Мне вот, как не-джаверу, было удивительно узнать, что в enum можно засунуть код - не все языки такое умеют :(

[@fidana_blog]

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

[@zentox8480]

Switch expressions придумали как раз чтобы устранить недостатки обычных свитчей, так что использовать можно и нужно.

[@СергейКондратенко-о9ц]

если б еще конструкция if else была только выражением, вычисляющим одно значение, то 'это приучило бы разбивать код на небольшие функции-методы

[@YanSokolovsky-o1t]

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

[@СэмФишер-х4д]

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

[@Dima-fr8cw]

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

[@brilliant_almazov]

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

[@Kenny251195]

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

[@ВолодимирК-р6т]

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

[@AntiSmithhh]

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

[@IPWchild]

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

[@0imax]

Вызов нескольких действий одним методом - это регулярная боль. И ладно если они всегда идут толпой, тогда в названии можно оставить более важное действие или придумать какое-то более общее название сему действу. А вот когда они же могут использоваться ещё и по-отдельности, то начинается веселье. И тут либо держать в голове (что уже плохо), что для конкретных случаев вызываем все три, а в других - вот эти два, либо сделать метод с "неправильным" названием, вызывающий три других метода.

[@VladisS.Vostok2000]

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

[@andreyburmagin3030]

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

[@СергейКондратенко-о9ц]

в Джаве недавно добавили такой вариант свича

[@andreyburmagin3030]

@@СергейКондратенко-о9ц жду, когда завезут в C++.

[@admenmod]

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

[@SamWhiteRK23]

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

[@Zohan136]

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

[@ОлегТокмачев-в9ц]

Мои коллеги не любят гард клаузы в начале метода, любят, чтоб по индийски было. Рад услышать, что мои предпочтения имеют отношения к нормальным практикам. А то я думал, я странный.

[@tmeMishaGo]

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

[@alexanderradzin1224]

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

[@alexandernikolaychuk8405]

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

[@oinochoe]

Я конечно понимаю, что год прошёл уже)) но.. возможно вы за год уже нашли ответ на этот вопрос?? Как, используете switch??

[@kuplumozga]

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

[@ОлегТокмачев-в9ц]

Читал Мартина и думал, ну длина метода в 10 строчек - это классно, я за. На практике я часто встречал монстров, но в целом благодаря гигантским мониторам было норм. Но вот сейчас мне приходится работать на 13 дюмовом лаптопе и я резко понял, что 10 строчек - это не красота и чистоплюйство, но это что-то, что может уберечь от нервного срыва и про уровни абстракции сюда же.

[@PavelSidorovich]

братюнь, если ты еще не совсем в нервном срыве: уменьши размер шрифта в IDE. если хоть пару строк сэкономишь - уже в дурку не попадешь!

[@at0m1x191919]

Круто!

[@igorpoznyakov5486]

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

[@joymusicstudio1]

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

[@NesseratiousChannel]

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

[@NikitaZenkin]

Изменилось ли как-то, в последнее время, ваше мнение о языке Go? В go как раз в switch не нужен break)

[@alexandrapersukova]

В новостях будет ответ на этот вопрос!)

[@АнатолийВ-п3д]

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

[@locktar-o-dark5664]

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

[@SergeyNemchinskiy]

вот миллион раз рассказываешь одно и то же, но все равно найдется человек, который ничего не услышит и все равно притащит уже разобранные доводы в тред. Не надо так

[@gaitavr1992]

Свич это нормально, если в нем нет логики, а обычный возврат нужной переменной. Например маппинг Enum - string и тд. С if/else это будет проблематично, ровно как и делить подобный метод

[@SergeyNemchinskiy]

'mkm код лучше перенести в сам enum

[@ІгорУхань]

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

[@torrvic1156]

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

[@sssauka]

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

[@АлексейПерцух]

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

[@mj_nooker]

Про switch, имхо: Сначала ужаснулся и подумал: "ну вот, а я думал, что это удобно и в некоторых случаях быстрее". Но потом понял, что тема видео - клин-код и не более. Т.е. тут данныц вопрос очень полезен в случае, когда нужен именно клин-код. Подумайте сами: в тех случаях, когда удобство и скорость свитча решает - ясен-красен, выбираем не клин-код, а скорость. И вуаля - когн.диссонанс ушёл.

[@0imax]

А где написано, что свич быстрее ифа? Компилится всë-равно в кучу условных переходов.

[@mj_nooker]

@@0imax гм, вычитывал в каких-то ("каких-то" - потому, что не помню в каких именно) доках по оптимизации кода в сторону скорострельности. Но ваше замечание интересное :) На досуге сделаю тест, чтоб развеять зародившееся во мне (благодаря вашей реплике) сомнение.

[@ДаниилСоловьев-э6ш]

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

[@АнатолийВ-п3д]

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

[@asobyanin]

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

[@Сергей-я9ф3у]

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

[@ValentinNechayev]

IDE типа IDEA умеет показывать имена аргументов - это тоже помогает. Но я тут за реформу языков в сторону явных имён в таких случаях (например, Swift позволяет требовать такое - явно назвать определённые аргументы).

[@yuriihizun7183]

Thanks!

[@msf_1984]

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

[@niknikagain]

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

[@John_Connor]

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

[@ГригорийТолстой-з3м]

Имеется ввиду по сигнатуре вызова тип obj.cancel(true, false, 42);

[@natalieastafeva4885]

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

[@LevPoptcov]

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

[@drl232]

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

[@dmitryvlasov931]

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

[@SergeyNemchinskiy]

приятно :) Люблю этого актера

[@playerkilleryakutia9415]

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

[@DiabloZq]

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

[@MarchenkoAnton]

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

[@feoktant]

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

[@PianoElipse]

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

[@user-uo2ph3ul3d]

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

[@dmitriy9232]

Спасибо! Годнота! Мальчика жалко ))

[@phpdevelopercode636]

А ну понял, в php недавно завезли enum. Нужно будет почитать

[@EgorychKononenko]

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

[@0imax]

В Java можно в enum нафигачить перегруженные методы для каждого значения, и вместо свича просто вызвать метод у енама, который отработает как полиморфизм в зависимости от значения этого енама.

[@John_Connor]

Читай DZone > Java Zone > Enum Tricks: Featured Enum Instead of Switch

[@torrvic1156]

А в C# как код положить? Что-то не видел такого. Не будете любезны и не подскажете?

[@nanvlad]

Я строго придерживаюсь правила: не больше одного выхода из метода, потому как если в методе несколько return, то значит в нем кроется несколько других методов. Да и длина метода чем меньше, тем лучше. 10 строк хватит с головой, стараюсь поместить в одну строку, но это уже функциональщина

[@SergeyNemchinskiy]

вы ошибаетесь, извините.

[@0imax]

Если в методе надо сделать проверку входных данных, а то и не одну - засовывать тело метода в if? Мне лично смотреть на такие ёлочки из ифов крайне неприятно. Проще на входе сделать иф (неправильный параметр) return и дальше уже заниматься своими делами. Опять же, если надо выйти из вложенного цикла, зачем городить огород, пробрасывая поток выполнения до конца метода просто ради того, чтобы выйти перед закрывающейся скобкой?

[@Grandjets]

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

[@トヤマトカナワ]

16:19 в целом то всё хорошо и правильно, но есть замечание к самому способу изложения и пояснения проблематики у вас часто и густо звучат фразы типа "ИДЕ помогает", "ИДЕ подсказывает", "ИДЕ за вас ....", и тут же вы 16:19 Тут уж либо ехать либо саночки! Если ваш код редачат через нано или нотпад - то да, аргумент абсолютно валиден. Но если его редачат через нормальную ИДЕ - она покажет какие поля как называются как минимум, а чаще всего и доку по методу, просто при наведении на него п.с. тоже касается и нулов в качестве возвращаемых значений Let the срач begin!

[@СергейКондратенко-о9ц]

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

[@КириллНеруш-б3э]

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

[@pond2949]

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

[@sergeynovikov9607]

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

[@prohorovgen]

Имейте в виду, что довольно большая часть этих советов справедлива только для очень старых языков по типу C и Java. Для любых нормальных современных языков (Swift, Kotlin, Dart, C#) часть этих советов не только не применима, но и весьма вредна.

[@evan_kirk]

А какие именно советы и почему?

[@feoktant]

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

[@AlexAlex-jk2tn]

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