Назви - це найважливіше з усього, що є у програмуванні. Уявіть поганий код, де все перемішано і викликається невідомо звідки. Якщо при цьому всі назви будуть продумані, осмислені та означатимуть саме те, що вони роблять, то програміст, який читатиме код, усе зрозуміє. Чи цікавить вас тема Чистого коду? Діліться своєю думкою в коментарях чи варто продовжувати цю рубрику👇👇
Зустрічав таку ситуацію коли, на існуйочуму проекті, замовник захотів перейменувати розділ сайту. Розділ це сутність яка має свою модель, класи, методи які до неї відносяться, простір імен. Так ось, на фронтенді назву розділу замінили, а на бекенді залишилось як було. Після того як нові розробники заходили на проект були сильно здивовані що розділ який називається "Call" , на бекенді це Job.
Кожен має свій дискурс і гадає про свій варіант вмісту. Без пояснень тупо не обійтися. Як не намагайся. Людський розум достатньо унікальний, щоб обмежуватися прямо аж усіма порадами.
Не зрозумів, чому приставки Provider, Manager, Processor, Helper, Mapper та інші на -er не можна використовувати? Це якісь вигадки. DataProvider,. TransactionManager, ScanProcessor, HtmlHelper and so on..
Дивлюся це відео і розумію наскільки айтішка різна. Я би сказав так: майже з усім погоджуюся, але треба пам'ятати, що в реальному житті неможливо завжди так писати, тому інколи треба покладатися на інтуїцію, досвід щоби зрозуміти яку назву дати
Хотілось би побачити чи почути саме про еволюцію від асемблера до інкапсуляції і структуризації в ооп. Бо в асемблері немає функцій, немає лексем з використання адрес. (На кшталт & * *(*) )Натомість є певні інструкції типу lea ld push pop і тому подібне. Ньюб розуміє тільки те що на поверхні - гарна структуризація і атомарність (!) ооп, але не саму її суть. Тобто чому є private i public можифікатори
Панове поправте мене. Чи варто прописувати в readme додаткову інформацію про функції які були використані при роботі на сайті. А тепер людською. Я на сайті додаю до корзини товар і при цьому задіяні 3 функції то чи потрібно прописувати так. Додавання товару > функція 1 > функція 2 > функція 3.(назви функцій використані для прикладу).
От для цього ші і створюють, бо як бачте людина має вміти читати😂😂 хоча з другого боку програміст має бачити паттерни, логічні послідовності і таке інше
How it will be better according to a clean code? Is it possible to check a value that is going to be returned from a getter and throw an error inside a getter? like this: get pagination() { const result = this.shadowRoot?.querySelector('pagi-nation') as HTMLElement | undefined | null; if (!result) { throw newError("There isn't a pagination."); } } Is it a good idea? Or it will be better to check a value outside.
.....-*er "класи" - то скоріше процедури. Якщо в коді такого багато - то навіщо вам взагалі ОО-мова? Анемічну доменну модель (якщо коротко - це коли в вас по суті лиш get/set/equals/hc в класі сутності) можна й не на ОО писати. Може вам так навіть зручніше буде. Щодо рефакторингу назв методів - тут можна і трохи прагматичніше бути. Наприклад якщо метод - це частина *публічного API бібліотеки, що використовується багатьма різними проектами* - його краще не перейменовувати, а задеприкейтити. Відрефакторений код перенести в інший метод уже з правильним ім'ям а з старого депрекейтнутого методу - просто викликати новий. І так - не місспельте методи, особливо публічні. Бо самі наражаєте себе на це пекло з деприкацією. Щодо хитрих назв і використання реальних бізнес термінів - ця порада звучить як: "не працюйте на внутрішньому українському ринку". address - це ще й дієслово. Типу: we should address this issue. Хоча так - синонімом замінити можна. Але це вже йде в розріз з "мовою замовника", ubiquitous language, оце все.
А чи може програміст чи команда змусити змінити замовника термін, якщо нададуть йому повну документацію з новою реалізацією? Бо частіше за все, будучи не в темі, замовник сам місспелить усе, а потім пиляй йому франкенштейна намагаючись не втратити здоровий глузд.
@@bidanfullko1 Думаю для того щоб змусити замовника змінити щось, а особливо щось звичне, треба мати communication skills рівня віртуоз. Але з такими скілами у вас вже не замовники будуть, а одні лиш меценати та фанатики.
ну, наприклад вам треба класс, який завантажує якісь дані з зовнішнього ресурсу. Назвати його лоадером - це саме логічне, що може бути. Особливо смішно, що є навіть паттерни креатор, ітератор, декоратор...
@@yaroslavzhurba670 Не дивлячись на те, що вперше більшість людей бачить ці паттерни в книжці GoF, але по суті ООП інструменти для цього не потрібні. Для декоратора потрібне просто посилання на функцію/процедуру. Тобто цей паттерн легко використовується як в хаскелі так і в C. Щодо лоадера, ітератора - ви самі не бачите, що ви виродили об'єкт до однієї єдиної утілітарної функції. Навіщо вам в такому випадку інкапсуляція? Та й предметну область уявити таку, в котрій лоадер моделює реальний об'єкт, а не є просто частиною механізму імпліментації достатньо важко. Скоріше це буде щось типу storage.upload(resource.asStream()) Під креатором ви мали на увазі Builder чи AbstractFactory? Хоча все одно ці речі - просто утілітарні церемонії. Але тут хоча б інкапсуляція потрібна для першого і поліморфізм для другого. Iterator, pointer, controller - туди ж. Нічого з цього не моделює ніякий процес з реального світу, а існує виключно як церемонія. У кращому разі - як клей між змодельованою предметною областю і інфраструктурою. З іншого боку в реальному світі іноді навіть люди зводяться до утілітарної функції. Наприклад коли декоратор може не тільки щось прикрашати, виконуючи роботу, а ще й брати вихідні - то він скоріше підтип працівника (Employee). І тут вже почнеться колізія в іменуванні якщо назви GoF чи інших паттернів використовувати в назвах сутностей.
@@oleksandrsova4803 Лоаадер може багато чого лоадати, тому не одна функція. Стораж у лоадера як раз скоріше повинен бути філдом, інакше ваш стораж стане суперобжектом, та точно не буде відповідати стораджу. Інкапсуляція потрібна для лоадера, бо він інкапсулює сторадж та якісь параметри коннекшену. Та навіть якщо одна функція та ніякої інкапсуляції не потрібно, то що, увесь проєкт тепер робити процедурним? Ми працюємо з абстракціями, а абстракції на те і абстракції, що до реального світу відносяться умовно. Мені дійсно цікаво як буде виглядати ваш код без використання ітераторів. Ну, і робітник нехай і без er, але вочевидь теж від слова робити. програмування це взагалі клей між тим що бажає замовник та виконується девайсом.
@@SerhiiNemchynskyi навіть foobar в певному дискурсі може бути логічною назвою, все залежить від того, що робить і де знаходиться метод. І якщо коли читаєш код метод з назвою foobar() буде читатися найближче до англійської мови, то воно буде зватися foobar і ніхто не зможе суперечити цьому, бо це буде тупо логічно
8:30 - це має сенс в С. Там немає неймспейсів, тому якщо це файл, яких буде відповідати за TCP, всі функції будуть починатись з tcp_ (звичайно, що не всі юзають це правило, але зазвичай цим користуються, щоб не здублювати назву функції якогось іншого файлу) 12:21 - Охохохох, ну тут індустрія з вами б точно не погодилась. Он, в Git з master в main перейменували. Так само як і з інтерфейсом SPI - був Master і Slave, став Controller і Peripheral
До цього ж - хіба abort це нормальне завершення? Нормальне скоріше буде exit (якщо себе) чи terminate (якщо дочірній процес) - хоча, можливо, це локальні традиції всюди свої...
Пане Сергію, уточню, що init - це не "початковий" від initial, а від initialize - "ініціалізувати", тобто запустити операцію. Тому метод так називався. Ця назва часто зустрічається в таких випадках.
Тут мова не про операційні системи чи драйвери. Тут про ентерпрайз, тому такий контекст не читається за замовчуванням.. Але залежить від розробника. Взагалі цей досвід транслюється в такому ключі, наче не існує дебаггера, щоб відслідкувати виклики об'єктів.
ви об'єм цього коду уявляєте? Там дебажити до того виклика треба було напевно добу :) а коли розкидаєш бряк пойнти, то треба розуміти куди саме треба його поставити
взагалі веселять поради а-ля - ну ти просто почитай код або дебагинг нас спасе, передивись структуру каталогів :))) Одразу розумієш, що люди звичайного ентерпрайз застосунка не бачили. Наприклад саме цей (тільки ця частина) важив 300+ Мб вихідного коду
@@SerhiiNemchynskyi А що не витягувало тоді дебагінг коду? Спроможності заліза? Я розумію контекст(масштабності проекту), і приблизний час коли це було. Але так виходить, що вам тупо не доступний інструмент з ряду причин. Тоді вже треба було б як у всіляких бродилка - малювати карту пройдених об'єктів і класів.. бо це реально нереальний експіріенс - вичитувати в ручну увесь код по кожній сутності(один раз таке було). Програміст має шукати вихід із "дурдому". От я і шукаю... наприклад візуалізацією джерельного коду. Було б таке раніше, і вам би допомогло. Впевнений.
Ось до речі чому я вважаю Го дуже поганою мовою: там обробка помилок робиться через повертання фактично кортежу з функції який неможливо використати потім у виразі й тому там потрібно вводити локальній змінні до кожного виклику функції. У той час як у "нормальних" мовах програмування введення змінної - це осмислений крок, змінна має мати назву, логіку й сенс існування у Го змінні вводяться з нагоди й без. А оскільки змінних багато - то прямо у офіційних гайдах дозволено називати їх однією літерою.
Зазвичай саме це і вважається кіллер-фічею го, ледь не на рівні з горутинами - те, що помилку достатньо складно *не* опрацювати. Ну й змінна дійсно має мати сенс. Навіть якщо це якась проміжна сходинка - у бізнес процесі, що модулює цей код має бути для цієї сходинки назва.
@@oleksandrsova4803 Ця "кіллер-фіча" на фоні Rust де обробка помилок зроблена одночасно й більш зручно й більш надійно виглядає як "фігак-фігак та у продакшен". Але так, після явних обробок помилок які зазначаються у сигнатурі функції повертатися до exceptions не хочеться.
@@oleksandrsova4803 Явне повернення помилки, яке прописане у сигнатурі функції це добре. Але Але у тому ж Rust обробка помилок зроблена й більш зручно й більш надійно одночасно. У Го дизайн мови здається робили за принципом "фігак-фігак та у продакшен".
Prompt: You are a signor developer with more than twenty years of commercial development experience. Rewrite this code fragment strictly according to Clean Code rules. Не благодарите!
звісно вміє. Але якщо коду справді богато, то як тільки ви поставили плейсхолдер, то одразу кількість співпадінній зрастаєв разі. Я якщо їх було кілько сотен...
