Как форматировать код правильно? Clean Code
Вставка
- Опубліковано 15 чер 2024
- Продолжаем курс лекций по Clean Code Роберта Мартина. Тема сегодняшней лекции это форматирование.
Новый поток курса Enterprise Patterns стартует уже 3 мая 2021 года!
Enterprise patterns - bit.ly/3vbecJt
Тайминг:
00:00 - вступление Сергея Немчинского
00:24 - приходи на продвинутый курс Enterprise Patterns в Foxminded !
01:32 - форматирование - важно
04:00 - как правильно форматировать код?
04:23 - метафора газетной статьи
06:07 - пропуски между концепциями
07:28 - вертикальная дистанция
09:33 - вертикальный порядок
10:55 - длина строки
14:30 - выравнивание
16:34 - расположение фигурных скобок, однострочные методы
19:24 - правила команды
Курсы для новичков:
JAVA - bit.ly/3dHlX3V
JAVA Start - bit.ly/3vpvLpx
PYTHON - bit.ly/3nahoCg
C# START - bit.ly/3xj4R4k
C#/.NET - bit.ly/3es5uj8
Инструментарий JAVA - bit.ly/3dJKaqy
Automation QA (Java) - bit.ly/2RR4k9j
ANDROID - bit.ly/3dHiKl5
FRONT-END - bit.ly/2QfO15L
SALESFORCE Developer - bit.ly/3tNFFRe
UI/UX дизайн - bit.ly/3vpvDq3
GAME DEVELOPMENT - bit.ly/3xauuEe
Обучение на проекте - bit.ly/3sHnYBE
Продвинутые курсы для состоявшихся девелоперов:
GRASP and GoF Design patterns - bit.ly/3enw11l
Другие услуги:
Пробное собеседование - bit.ly/3awwFIO
Карьерная консультация - bit.ly/3etbsAF
Сайт Foxminded: bit.ly/3xatTlY
Foxminded в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
Foxminded в VK: foxminded
Мой Telegram: t.me/nemchinskiyOnBusiness
Для деловых запросов: youtube@foxminded.com.ua
#nemchinskiy #ityoutubersru #cleancode
Форматировать код надо вместе с диском. Тогда уж точно будет CLEAN!
Всё чаще и чаще я слышу от разных людей что знают Сергея Немчинского
Хотелось бы увидеть примеры, "как правильно(красиво)" и "как ужасно" ...
воображения не хватает?)
Да
Поищи сайт про гавнокод, там много интересного
Наверное надо посмотреть на свой код 🤣
@@TimC0x 80% визуально. процентов 15 на слух осязание и тп. думаю на воображение не больше 5 остается
Спасибо, Сергей! Очень полезная серия лекций!!!
Спасибо, наш дорогой Сергей Немчинский 🤝😉
Спасибо, жду следующих выпусков.
Спасибо большое, тема очень актуальная
Спасибо за видео!
Стоило сказать про инструменты для автоматического форматирования. Если у вас на проекте есть editorconfig и настроен линтер, то никаких проблем с конфликтами у вас не будет: либо ты пишешь как надо, либо CI выпинывает твои реквесты, пока не сделаешь красиво. Большинство ИДЕ подхватывают эти правила и за тебя всё форматируют.
ага, у нас на джаве СонарКуб
Просто и понятно. Спасибо Вам.
Захотелось в некоторых коллег с предыдущего места работы кинуть книжкой по Клин Коду и этим видео....
Однострочные IF FOR WHILE, прям обмазывались ими... То же самое и однострочные методы. Причем, так кодили люди с 20 летним стажем.
От части поэтому и уволился, читать и работать с таким кодом - спасибо, я пас.
Спасибо за видео, Сергей
спасибо, очень интересно и полезно, ждем продолжения
Мой любимый code style скобок для python)
Только учусь, но интересно и продуктивно.
Классная тема))
Спасибо за видео, и хотелось бы наглядности
Няшная лисичка на футболке.
какая классная у вас футболка))
Как относитесь к LLVM стилю для C++?
Я то думал что будет бесполезное видео, но решил посмотреть на всякий случай. Оказалось довольно полезное видео, свой код стараюсь делать так как будто что кроме меня будет другой сопровождать. На самом деле я его и сопровождаю в 100% случаях. В команде работал давно и уже забыл многие холивары. Сергей вот вопрос у меня возник. Я сейчас работаю по слаботочке (охранка, пожарка, видеонаблюдение), у нас на работе есть каждые 3 мес. квалификационные экзамены, по результату которых можно не только стать техником, но и вылететь из компании. Есть ли подобная практика в IT-компаниях?
альт стрелка назад, почему я этого не знал? ааааа 😂
Доброго дня! Очень нравятся ваши видео из такой рубрики! Единственное не хватает практической части - например на каком-либо языке. Допустим той же Java, или любой другой.
Сделайте плейлист
А как на счет --check в гите чтоб он на пробелы проверял?
Как форматировать HDD правильно?
Молотком. Раз и навсегда.
микроволновкой!!
@Svetlana V ахахахах спасибо)
format c: /y
Просмотрел ролик и никак не могу понять, а как же все-таки помыть кота?
Верните старое форматирование бороды Немчинскому!
Боже храни PEP8 )))
Как же быть с длинными строками, которая не влезает в монитор? Переносить ее на новую строку? Когда это оправдано, а когда лучше оставить все на одной?
Кажется про статические методы и private final static не сказано
👍
Сегрей вы гений рекламы.)
Можно же включить перенос строки в IDE. Тогда с длинными строками не будет проблемы. Хотя, я сам, кончено, не фанат такого дела. Тоже предпочитаю вручную разбивать длинные строки.
В Python по pep8 длинна строки не должна быть больше 79 символов
В пайтоне все же проще немного поместиться в эти 79 символов, там другие неймин конвеншенс чем в джаве, не нужно объявлять типы, нету геттеров/сеттеров и так далее. В общем мне кажется в пайтоне еще можно работать с этими 79 символами, когда в джаве это конечно как сказал Сергей - вообще наркомания. Но конечно обидно немного когда работаешь за большим монитором а прерывать линию надо на 79ом символе))
Если честно не понял одного момента... как вас зовут?
Сергей, вы в принципе и по его книге можете запустить курс. С более подробными объяснениями.
Можете поделиться мнениями, почему самое важное в классе это поля? Разве не публичные методы, так как они является интерфейсом и это первое, что по идее должен видеть другой разработчик. Всё остальное для него - black box.
Я сам визуально предпочитаю сначала поля потом методы, но как-то с точки зрения логики это неправильно.
Так поля тоже могут быть публичными. И даже, если все приватные, то они используются в методах. Соответственно, они первичнее и важнее. Думаю, как-то так.
@@Disc0veryX исходя из первого принципа ООП, "пользователю" класса должно быть до фонаря, какие там внутри поля. Главное в большинстве классов - методы, поэтому паблик методы всегда пишу первыми, потом приватные поля, потом приватные методы.
Блин, Серег - выглядишь гораздо лучше. Завел любовницу и она тебя откормила? :D
Загадочная История Сергея Немчинского)))
А если, например, if двухстрочный, с отступом, но без скобок, это плохо? Плюс вертикальный отступ. Смотрится довольно неплохо.
Мне тоже нравится вариант без скобок, и такой вариант рекомендован в Qt.
Проблема забытых операторных скобок по мне так весьма надумана - добавляя второй оператор в такой иф, эту скобку автоматом пишешь и автоматом же проверяешь, есть ли открывающая.
А когда идёт куча ифов, разделяемая строкой с одной закрывающей скобкой - выглядит не очень, а если отделять ещё и пустой строкой - то впустую расходуется вертикальное пространство, более ценное, чем горизонтальное.
пример?
@@maxlich9139
If (something)
foo();
if (something_else)
bar();
...........
Где-то читала, что если if в одной строке - можно без скобок. Но как только он переходит на новую строку, то скобки обязательны. Даже если отступы. Без скобок можно не заметить и между строками if вставить что-то новое а потом какое-то время тупить, что тут происходит.
Else считается как часть if, то есть, если else на новой строке - ставим скобки.
Ну или как сказал Сергей - всегда ставить скобки и не думать об этом)
Для отделения блоков кода #region)
А зачем регулировать количество отступов, если (не знаю по другие IDE) (я про C#)Visual Studio по комбинации клавиш Ctrl + K + D выравнивает все под настройки выставленные пользователем, есть ещё адаптация кода, к примеру копируешь код с Stake Overflow, а там первая фигурная скобка в одной строке с объявлениями метода, скобки с параметрами через один пробел а отступ (табуляция) не 4 пробела а 2, и вставляешь этот код в Visual Studio и он автоматически, без каких либо телодвижений, форматируется под настройки IDE так как выставил пользователь. Так что особо необходимости в регуляции отступов я не вижу.
относительно сортировки методов - тут довольно много конфликтующих штук по которым логически хорошо группировать, типа сначала паблики потом приват, сначала паблик потом приватные методы этого паблика, сначала поля, потом, свойства, потом методы, сначала одна область ответственности потом другая. я сколько программирую так для себя и не выработал какую-то постоянную модель, все как-то от случая к случаю скачет) когда-то давно когда программировал на делфи и у нас там были гигантские портянки с кучей классов - был какой-то плагин который показывает классы, их методы и другие внутренности в понятном компактном виде, навигировался по нему и этой проблемы с поиском вообще не стояло) сейчас на более совершенном C# возникают подобные проблемы иногда (в рамках 1 маленького класса, а не портянки конечно же)
Никогда не понимал, зачем после паблик метода писать его приватные. Зачем тратить кучу времени на перечисление всех приватных методов, чтобы явно указать зависимость паблика на приваты, которой потом всë-равно никто не пользуется, а интерфейс класса изрядно портится. Тем более что некоторые приватные методы могут вызываться несколькими паблик методами и несколькими приватными. Пытаться отразить эти зависимости путем размещения вызываемых методов под вызывающими - бесперспективное занятие.
Пользователю класса важен интерфейс - его и пишу в первую очередь, возможно, разбив методы по группам. Потом приватные поля и приватные методы.
Всë. Никаких попыток отразить структуру связей порядком объявления методов. Не нужно это.
Будут рефакторить какой-то метод - посмотрят сами, какие методы он вызывает, и какие методы вызывают его, благо ИДЕ это делает легко и просто.
@@0imax код не всегда пишется под стороннего пользователя класса, иногда он пишется скорее для себя (особенно в процессе разработки или когда часто приходится там что то менять), а когда знаешь внутреннюю работу, часто удобнее иметь приватное вначале, или такую вот группировку по паблик и его приватным частям. к примеру когда пишешь код то переменные приватные в начале класса объявлять как-то удобнее получается чем в конце (несмотря на то что они приватные). для пользователя класса, который хочет видеть интерфейс класса в первую очередь я согласен нужны паблики вверху.
@@jgkdmdevienjjgg8866 в таком случае я просто пользуюсь двумя окнами с одним и тем же классом: в одном окне пишу код, а второе перемотано вниз до нужных приватных полей или методов.
Ок
ЗДАРОВА БАТЯ.
Ох. Моя проблема, что я начинаю исправлять форматирование в некоторых мелочах. Да, оно было неправильно, но в мёрдж реквесте оно есть и мне прилетает от лида 😅
Раньше тоже ставил пробелы Табом, а потом один умный человек подметил, что большинство к Табам относится не верно. Табы, наоборот нужно сделать стандартом. Вот у вас есть общий code style и в нем Табы вместо пробелов, и хочешь, ставишь, чисто для себя, отображение Таба как 2-х пробелов, хочешь - как 4-х, а если нравиться, то и как 8-ми пробелов, и это никак не отразится на общем коде и не будет никаких конфликтов.
Тот же файл настроек code style умеет подтягивать git, а на крайний случай есть настройка в профиле, отвечающая за количество пробелов для одного Таба.
Умного человека зовут Вадим Макеев? Знакомые тезисы)
@@user-dv9fk1hd3s честно, не помню, просто ролик из Ютуба как-то раз на глаза попал.
использовать prettier и забыть о форматировании на совсем?
python не использует скобки вообще. именно возможность последующей правки с потерей логики и напрягает.
Да, выкидывать скобки в заботе о форматировании было не лучшей идеей. Получился язык, где пробел - значащий символ.
whitesmith forever
У нас в компании лимит - 120 символов в строке, иначе пайплайн на гите обосрется, а с обосранным пайпалайном никто мержить не будет. И исправление зафейленых пайплайнов лежит на том, кто создает мерж.
По поводу величины "табуляции": я где-то когда-то видел плагин для саблайма табуляция фибоначчи, чтобы бороться с дохера вложенными блоками. Первый блок - 1 пробел от предыдущего уровня по вертикали, второй - 2, третий - 3, четвертый - 5, и далее по ряду фибоначчи. Но это скорее ради фана, на реальных проектах никто такое юзать не будет...
19:05 в этом плане мне понравился подход golang-а. Там без правильного форматирования даже код не скомпилируется.
А про пробелы между идентификаторами и операторами? Ну как же так, Сергей? Самую важную вещь - и забыли! А потом из ваших курсов и выходят говнокодеры, пишущие какой-то обфусцированный код.
Я иногда использую однострочные if - в связке с операторами break, continue, return. У меня бывает, что методы имеют неприличную длину, и в таких случаях из-за одного слова превращать 1 строку в 3 мне кажется бОльшим злом.
В подобных случаях просто пишу двухстрочный иф без скобок. Много на однострочных ифах не сэкономишь, зато читать приятнее.
Если метод настолько длинный что приходится экономить на скобках, то может его как-то отрефакторить, разбить на несколько?
Не понимаю, зачем настраивать свою IDE под форматирование кода, потом ещё файл настроек рассылать всем коллегам? А если у них другие редакторы кода?
Установил eslint, накатил конфиг популярный и всё. Далее, в процессе разработки, вносишь в него свои правки и радуешься...
С php, например, нынче можно в composer.json в раздел скрипты засовывать форматировщики с путями к конфигам относительно json-а. И потом суёшь эти конфиги в гит в корень проекта, а IDE уже автоматом после установки зависимостей (включая эти самые форматировщики) применит указанный конфиг.
У меня от стиля скобок K&R горит прям... Хоть и пишу на Swift, но предпочитаю Allman. А подстраиваться под вкусы разработчиков языка... ну такое.
а что там в этой вашей жаве нету автоматических инструментов стилизации кода?
есть во всех основных ide. но ее можно катомизировать. и даже верификаторы есть
в С раньше было два или три основных стиля форматирования : по Кернигану, gnu
На мой взгляд, разрабатывать на ноуте - капец, как неудобно. Это, если только он подключен к монитору, а ещё лучше 2 через док-станцию, тогда совсем другое дело.
Клин Кот
длинную строку банально неудобно читать, охватить взглядом все выражение не мотыляя головой или не тягая ползунком....
я питонист
@@@
ставлю себе 79 символов в длинне
@@@
слышу о "а вдруг у вас 200 символов"
@@@
улетаю в стратосферу
на питоне принято использовать небольшие простые названия, поэтому там нет такой проблемы как в коде на джаве со спрингом
@@user-qy7dc3oq2i это понятно, просто страшно стало
Очень жаль что нет примеров, очень сложно слушать и представлять одновременно
Рекомендую скрыть видео, и отправить на доработку)))))))
Сложно только если не натыкался на такое в реальном коде.
Переходіть на Go, і забудьте про форматування
Вот в не очень любимом Сергеем Golang с фораматированием все хорошо. Оно уже зашито и не надо лишний раз договариваться.
А ще є випадки, коли треба через телефон зайти під час відпуску на бітбакет і апрувнути якись комміт 😆
Не хочу придираться но картинка на видео ну уж сильно засветлённая!
Кошмар, сколько проблем на ровном месте. Не ожидал что все так плохо. Никому не приходила в голову идея хранить код вобще без форматирования, а само форматирование переложить на иде? Кому как удобно иде автоматом отформатирует и покажет на экране, а при сохранении уберет все форматирование. Так же и при мерджах.
Идея интересная, но есть подводные камни. Например, что делать с пустыми строками, с переносами строк, с вертикальным выравниванием параметров функции, когда их много или длинные имена аргументов.
В общем, как отделить автоматически сгенерированное форматирование от того, которое сделано вручную для лучшего восприятия.
а ещё во многих организациях и командах принято отправлять код на ревью своему коллеге и это делается в гите (не скачивая и не открывая в IDE)
@@user-wk5fm5qw1f А для гита нельзя написать просмотрщик? В целом я себе это представляю как с json. Там тот же синтаксис что и в коде. Но хранится он в одну строчку, а разными просмотрщиками отображается с отступами, группами и т.п.
Ctrl+a, Ctrl+alt+l. Всё. Ролик ещё не смотрел.
Хз что в других языках, в пхп народ сделал psr стандарты, пара из которых описывают правила форматирования, шторм уже имеет встроенными эти правила, включил и пиши. Для всей команды. Неудобно? Твои проблемы. Переучивайся. Всё.
В битриксе зачем то завели свои правила форматирования кода, которые как будто нарочно противоречат почти каждому пункту PSR. Вот ведь извращенцы)
11:28 Кому привет...?
Spring’y
я фанатею от программирования на ноуте. и от игр на ноуте, и ведения домашней бухгалтерии на ноуте, и все прочего на ноуте и уже просто не понимаю, зачем нужен громоздкий стационарный ПК, особенно в контексте жизненной мобильности разработчиков. 😎
Я плачу от работы на ноуте, и программирования на ноуте, и всего остального на ноуте. Не понимаю, зачем нужен неудобный ноут, если можно купить нормальный большой стационарный компьютер. Особенно в контексте жизненной статичности разработчиков
Без картинок и примеров очень плохо воспринимается, даже у мартина есть примеры.
Зачем нужен такой кот, который сам себя не может помыть?
Погодите. У нас же было 10 классов на файл, 10 строк на метод, 10 методов на класс. Итого максимум 1000 строк. Зачем это ещё украшать?
Как бы так выразится - говорите вначале про современные ide, а потом про длину строки - а ничего что современные ide легко решают проблему длинны строки именно под ваш монитор. На практике, длинные команды редкость, а параметры строк и т.д. лучше не разделять.
Чтоооо? Молодые программисты любят пробелы? Я сам только устраиваюсь на первую работу и заканчиваю магистратуру в институте и не встречал ни 1 человека, предпочитающего пробелы, все и всегда используют табуляцию. (А круг общения у меня широкий, и студенты, и люди с приличным опытом)
Однако чукча не читатель, чукча писатель