Вітаю, мої дорогі, мене звати Сергій Немчинський, я програміст з досвідом в розробці понад 20 років, один з моїх талантів - це пояснювати складні речі простими словами, а також я обожнюю навчати людей та бути корисним. Це другий випуск з серії україномовних відео про Чистий код. Сьогодні ми говоримо про те як правильно писати методи. В минулому відео ми говорили про те як правильно називати змінні, методи та класи. Зберігайте цей плейлист собі та діліться ним з друзями, які теж тільки опановують програмування - ua-cam.com/play/PLQJzwIE9GGfghZ_gykxbHwDaJWeiYGtKL.html 💙💛Ставте вподобайки та підписуйтеся на цей канал!
DRY це не дублювання коду, це як на мене єдине джерело істини. Тобто будь що, однакові значення, алгоритми, порядки дій мають бути визначені один раз в одному місці, а задля їх використання слід звернутися до цього місця. Наприклад, якщо у css у вас є синє небо й синя кніпка й зараз вони однаково сині - це мають бути дві РІЗНІ змінні/константи.
Мої дорогі. Життя мені показало, що контекст первинний та куди важливіше правил. Мудрість розробки - це коли ми формуємо свої правила під свій уникальний проект та іноді їх свідомо порушуємо, знаючи чому або заради чого. А ще, регулярно їх переосмислюємо та модифікуємо, бо вони повинні лишатися адекватними постійним змінам та потребам на живому динамічному проекті. А ті, хто ставить правила вище здорового глузду та адаптивної гнучкості кінчають погано. Знаю що кажу. Всім розуму!
if..else..if..else якраз анти-паттерн! ЗАВЖДИ старайтесь використовувати switch - це зменшує компексетивність і дозволяє легко створювати "важку" логіку з легкою реалізацією, особливо, якщо не "пихати" код всередину switch а використовувати методи. Окрім того, до switch дуже легко додавати нову логіку, натомість з if-ами можн алегко щось поламати.
Как бы вы сами себе противоречите, если у вас ВЕСЬ метод должен помещаться на экран, то и Свитч должен помещаться на экран, потому что Свитч это лишь часть метода. Более того, вы застряли на Джава 8? В 13й версии добавили новый Свитч, где нет этих брэйков. Так что это вдвойне страннее гнать на Свитч в новых реалиях.
Дякую Сергію за цікавий контент, дійсно корисний канал з чудовими відео. На рахунок методів без параметрів - є альтернативна думка. Метод без параметрів вимагає створення StateFull об"єктів. А якщо є стейт, є й необхідність його контролювати, що веде до написання додаткового коду - що контролює стейт. А якщо є один стетйфулл об"єкт, що залежить від іншого стейтфулл об"єкта - складність такого коду росте геометрично, також такий код дуже тяжко дебажити і рефакторити. Тому, є така думка, яку розділяють багато наших колег - краще писати стейтлесс код. І, як було сказано в другій частині відрізку про методи, якщо є велика кількість параметрів, їх можна організовувати в групи (конфігурації) або таки варто подумати над рефакторингом методу - розділити параметри і логіку методу на логічно спорідені групи. П.С. Ще раз дякую за ваші відео, Сергію :)
Чи можна порушити правило "Об'єкт може міняти лише void", Якщо метод має створити об'єкт, або внести кудись дані, і повернути id цього об'єкта (Елемента масиву, тощо)? Часто таке зустрічаю, мені це з точки зору логіки не дуже подобається, але іноді це найпростіший спосіб отримати id, не створюючи якісь додаткові поля, чи методи для отримання останнього id
Що це за маячня??🤭 "...я створив декілька методів Cancel..." Тобто це як? Наприклад є метод Cancel який приймає два boolean які кажуть методу: Занотуй в лог в консолі (перший прапорець) та занотуй в лог файл (другий прапорець) а сам метод до прикладу 100 стрічок... І от у автора вийшло загалом 200 стрічок сукупно, які відрізняються тільки стрічкою куди треба логувати? 🤨 Єммм... Оцьому його фірма вчить? Пишіть кода стільки щоб будь-хто поперхнувся? Жах...
Стосовно switch у сучасних мовах замість нього є match (Rust та зненацька PHP) який не має цих недоліків й може використовуватися як вираз. Ще є го, де switch також не провалюється, але він примусово форматується так, що й switch й гілки встановлюються на одному рівні - таке могла зробити лише людина, яка ненавидить програмування й програмістів... Ще додам важливу перевагу match: в ній мають оброблюватися ВСІ можливі варіанти.
"Змінювати об'єкт повинен тільки метод void" А як ще повернути модифіковану копію, якщо у нас імутабельність? Взагалі, пишу на Котліні та Дарті вже багато років, всі поля в класах в мене завжди val та final, кейворд var в функціях використовую мабуть раз на ~5000 стрічок, і це просто з тієї причини, що нема часу шукати нормальне рішення з імутабельністю. Змінювати об'єкти в 2024 році, це якась дичина.
Про side-effect у getter'і: певне оригінальний автор не правильно використав паттерн Flyweight. Без контексту складно сказати чи можна було зробити краще чи в цьому була якась необхідність. Але, як правило замість створення Flyweight чи ще якогось lazy - краще розбити код на декылька юзкейсів і запускати юзкейси вже повністю відбудованими тому що ви тоді точно знатимете що всі залежності вам потрібні і немає сенсу ініціалізувати якусь з залежностей пізніше.
Як це не використовувати свіч? А when можна, чи теж ні? Зовсім відстали від часу зі своєю дубовою жабою чи з якимось іншим гівном мамонта. У всіх нормальних сучасних мовах він якщо так і зветься, то працює як match, або якось по-іншому зветься, але все одно працює як match. А в Дарті навіть коли використовується як звичайний старий свіч (без стрілок), то нікуди нижче поточного кейсу не провалюється, тому не потребує ніякого brake.
13:45 "Не використовуйте аргументи як результат" й наступне про void - це проблема поганого дизайну мови. Тобто є жахливі мови, як от JS де тип аргументу пишуть у коментарі біля функції, є просто погані мови, як от Java або Go де вже можно вказати тип аргумента але ще не можна вказати якщо це посилання чи є воно мутабельним. Та є Rust у якому по-перше у сигнатурі функції явно вказується чи буде мутовано об'єкт який ми в неї передаємо, а по-друге якщо ми передаємо посилання на об'єкт ми просто не зможемо повернути цей об'єкт бо ми не опановуємо його.
16:29 як не знаєте? Розкажить коли код повинен повторюватись: 1. якщо виклик коду займає більше коду ніж сам код; 2. якщо часто змінюєтсья один з дублів коду і не відомо який
Вимова - це щось! Але коли я переходив на українську, в мене було ще гірше. З часом стане значно краще, головне не припиняти практику. Дякую за гарний контент! Нарешті зупинив кров із вух. 😛
міцного. 02:06 - а якщо монітор 32 дюйми? ) метод дуже великий тоді все одно. моє бачення - повинно бути комфортно читати код в методі, щоб поки ти дійдеш до кінця метода, не забув що спочатку метода. дякую за відео.
Вітаю, мої дорогі, мене звати Сергій Немчинський, я програміст з досвідом в розробці понад 20 років, один з моїх талантів - це пояснювати складні речі простими словами, а також я обожнюю навчати людей та бути корисним.
Це другий випуск з серії україномовних відео про Чистий код. Сьогодні ми говоримо про те як правильно писати методи.
В минулому відео ми говорили про те як правильно називати змінні, методи та класи. Зберігайте цей плейлист собі та діліться ним з друзями, які теж тільки опановують програмування - ua-cam.com/play/PLQJzwIE9GGfghZ_gykxbHwDaJWeiYGtKL.html
💙💛Ставте вподобайки та підписуйтеся на цей канал!
DRY це не дублювання коду, це як на мене єдине джерело істини. Тобто будь що, однакові значення, алгоритми, порядки дій мають бути визначені один раз в одному місці, а задля їх використання слід звернутися до цього місця. Наприклад, якщо у css у вас є синє небо й синя кніпка й зараз вони однаково сині - це мають бути дві РІЗНІ змінні/константи.
Дуже не вистачає прикладів на екрані. Дякую
Мої дорогі. Життя мені показало, що контекст первинний та куди важливіше правил. Мудрість розробки - це коли ми формуємо свої правила під свій уникальний проект та іноді їх свідомо порушуємо, знаючи чому або заради чого. А ще, регулярно їх переосмислюємо та модифікуємо, бо вони повинні лишатися адекватними постійним змінам та потребам на живому динамічному проекті. А ті, хто ставить правила вище здорового глузду та адаптивної гнучкості кінчають погано. Знаю що кажу. Всім розуму!
@@oeaoo сліпе слідування правилам - ознака незрілості) Але це все ж краще ніж взагалі не знати правил)
дякую за українськиц контент!
if..else..if..else якраз анти-паттерн! ЗАВЖДИ старайтесь використовувати switch - це зменшує компексетивність і дозволяє легко створювати "важку" логіку з легкою реалізацією, особливо, якщо не "пихати" код всередину switch а використовувати методи. Окрім того, до switch дуже легко додавати нову логіку, натомість з if-ами можн алегко щось поламати.
В 21 Java додали switch pattern matching, дуже рекомендую
Дуже хороший формат, прошу продовжуйте робити такі ролики: антипатерни - чому так не треба робити, з коментарями з власного досвіду
Дякую, будемо продовжувати
Как бы вы сами себе противоречите, если у вас ВЕСЬ метод должен помещаться на экран, то и Свитч должен помещаться на экран, потому что Свитч это лишь часть метода.
Более того, вы застряли на Джава 8? В 13й версии добавили новый Свитч, где нет этих брэйков. Так что это вдвойне страннее гнать на Свитч в новых реалиях.
Звучить все легко , але на ділі дуже важко слідувати цим правилам
Дякую за цікавий контент!
Дякую! Чудове відео. Дуже багато у вас навчився.
15:24
Return замість returne
Дякую Сергію за цікавий контент, дійсно корисний канал з чудовими відео. На рахунок методів без параметрів - є альтернативна думка. Метод без параметрів вимагає створення StateFull об"єктів. А якщо є стейт, є й необхідність його контролювати, що веде до написання додаткового коду - що контролює стейт. А якщо є один стетйфулл об"єкт, що залежить від іншого стейтфулл об"єкта - складність такого коду росте геометрично, також такий код дуже тяжко дебажити і рефакторити. Тому, є така думка, яку розділяють багато наших колег - краще писати стейтлесс код. І, як було сказано в другій частині відрізку про методи, якщо є велика кількість параметрів, їх можна організовувати в групи (конфігурації) або таки варто подумати над рефакторингом методу - розділити параметри і логіку методу на логічно спорідені групи. П.С. Ще раз дякую за ваші відео, Сергію :)
Pure functions to the rescue!
Контент супер, так тримати!
Чи можна порушити правило "Об'єкт може міняти лише void", Якщо метод має створити об'єкт, або внести кудись дані, і повернути id цього об'єкта (Елемента масиву, тощо)? Часто таке зустрічаю, мені це з точки зору логіки не дуже подобається, але іноді це найпростіший спосіб отримати id, не створюючи якісь додаткові поля, чи методи для отримання останнього id
Що це за маячня??🤭
"...я створив декілька методів Cancel..."
Тобто це як? Наприклад є метод Cancel який приймає два boolean які кажуть методу: Занотуй в лог в консолі (перший прапорець) та занотуй в лог файл (другий прапорець) а сам метод до прикладу 100 стрічок... І от у автора вийшло загалом 200 стрічок сукупно, які відрізняються тільки стрічкою куди треба логувати? 🤨
Єммм... Оцьому його фірма вчить? Пишіть кода стільки щоб будь-хто поперхнувся? Жах...
Точно "понад"? Мабуть хотіли сказати сказати не більше 10 рядків?
Про switch - спірний момент з урахуванням останніх синтаксічніх змін в java 17
Дякую, цікаво і корисно
Про довжину метода: в Гуглі стандарт на довжину рядка!!! 80 символів :)
Стосовно switch у сучасних мовах замість нього є match (Rust та зненацька PHP) який не має цих недоліків й може використовуватися як вираз. Ще є го, де switch також не провалюється, але він примусово форматується так, що й switch й гілки встановлюються на одному рівні - таке могла зробити лише людина, яка ненавидить програмування й програмістів...
Ще додам важливу перевагу match: в ній мають оброблюватися ВСІ можливі варіанти.
"Змінювати об'єкт повинен тільки метод void"
А як ще повернути модифіковану копію, якщо у нас імутабельність?
Взагалі, пишу на Котліні та Дарті вже багато років, всі поля в класах в мене завжди val та final, кейворд var в функціях використовую мабуть раз на ~5000 стрічок, і це просто з тієї причини, що нема часу шукати нормальне рішення з імутабельністю. Змінювати об'єкти в 2024 році, це якась дичина.
Про side-effect у getter'і: певне оригінальний автор не правильно використав паттерн Flyweight. Без контексту складно сказати чи можна було зробити краще чи в цьому була якась необхідність. Але, як правило замість створення Flyweight чи ще якогось lazy - краще розбити код на декылька юзкейсів і запускати юзкейси вже повністю відбудованими тому що ви тоді точно знатимете що всі залежності вам потрібні і немає сенсу ініціалізувати якусь з залежностей пізніше.
Я б не згадував про Enum зовсім. Тільки поліморфізм.
Як це не використовувати свіч? А when можна, чи теж ні? Зовсім відстали від часу зі своєю дубовою жабою чи з якимось іншим гівном мамонта. У всіх нормальних сучасних мовах він якщо так і зветься, то працює як match, або якось по-іншому зветься, але все одно працює як match. А в Дарті навіть коли використовується як звичайний старий свіч (без стрілок), то нікуди нижче поточного кейсу не провалюється, тому не потребує ніякого brake.
Гарна метафора з масштабом карти. Ніби очевидно, але корисно. Візьму на озброєння)
13:45 "Не використовуйте аргументи як результат" й наступне про void - це проблема поганого дизайну мови. Тобто є жахливі мови, як от JS де тип аргументу пишуть у коментарі біля функції, є просто погані мови, як от Java або Go де вже можно вказати тип аргумента але ще не можна вказати якщо це посилання чи є воно мутабельним. Та є Rust у якому по-перше у сигнатурі функції явно вказується чи буде мутовано об'єкт який ми в неї передаємо, а по-друге якщо ми передаємо посилання на об'єкт ми просто не зможемо повернути цей об'єкт бо ми не опановуємо його.
16:29 як не знаєте? Розкажить коли код повинен повторюватись: 1. якщо виклик коду займає більше коду ніж сам код; 2. якщо часто змінюєтсья один з дублів коду і не відомо який
Вимова - це щось! Але коли я переходив на українську, в мене було ще гірше. З часом стане значно краще, головне не припиняти практику. Дякую за гарний контент!
Нарешті зупинив кров із вух. 😛
Супер!!! Дякую Вам!!!
Дуже пізнавальне відео. Комент для активу
дякуємо!
Цікаве нагадування як треба чистий код писати - не зупиняйтеся
міцного. 02:06 - а якщо монітор 32 дюйми? ) метод дуже великий тоді все одно. моє бачення - повинно бути комфортно читати код в методі, щоб поки ти дійдеш до кінця метода, не забув що спочатку метода.
дякую за відео.
Випуск 🔥Але до цього треба дорости, трохи по##атися з кодом)))
Void метод, це той що нічого не вертає? Тобто процедура?
1:56 "Длина метода должна быть не больше одного экрана" Ведь никто потом не будет же поворачивать 32-дюймовый экран вертикально? Не будет же? 🙂
Дякую за хороший контент!
Про функціональну парадігму давайте. Бо з ООП і 10 строчок викручує мізки
тому і розвертаю монітор на 90 градусів :)
Дякую, за українську мову❤
Комент для просування
Дякую за корисну інформацію.
Чекаємо мото-відео на іншому каналі)
Ох, я спробую)
Дякую за це відео ✌🔬
Golang: return err)))
дякую за відео, вподобайка та й коментар для популяризації контенту
Допомагаймо ЗСУ!
В мене дома кажуть, що ваша українська суттєво покращилася 😊
Дякую за відео, робіть ще)