Яка ідеальна тривалість методу для вас? [зачинено]

У об'єктно-орієнтованому програмуванні, звичайно, немає точного правила щодо максимальної тривалості методу, але я все-таки виявив, що ці два цитати дещо суперечать один одному, тому я хотів би почути, що ви думаєте.

У чистому коді: Підручник з гнучкої майстерності програмного забезпечення , Роберт Мартін говорить:

Перше правило функцій полягає в тому, що вони повинні бути невеликими. Друге правило функцій полягає в тому, що вони повинні бути меншими за це. Функції не повинні бути довжиною 100 рядків. Функції навряд чи повинні бути довгими 20 рядків.

і він наводить приклад з коду Java, який бачить у Кента Бека:

Кожна функція в його програмі мала всього два, три чи чотири рядки. Кожен був прозоро очевидним. Кожен розповів історію. І кожен привів вас до наступного в переконливому порядку. Ось якими короткими повинні бути ваші функції!

Це звучить чудово, але, з іншого боку, у Code Complete Стів МакКоннелл говорить щось зовсім інше:

Зазвичай слід дозволити органічному зростанню до 100-200 рядків. Десятиріччя свідчать, що підпрограми такої довжини не мають більше помилок, ніж коротші процедури.

І він посилається на дослідження, яке каже, що рутини 65 ліній або довше розробляються дешевше.

Тож, хоча існують різні думки з цього приводу, чи є функціональна найкраща практика для вас?

Функції, як правило, повинні бути короткими, між 5-15 рядків - це моє особисте "правило" при кодуванні на Java або C #. Це хороший розмір з кількох причин:

• Він легко розміщується на екрані, не прокручуючи
• Йдеться про концептуальні розміри, які ви можете потримати в голові
• Це досить значуще, щоб вимагати функції самостійно (як окремий, змістовний фрагмент логіки)
• Функція менше 5 рядків - це натяк на те, що ви, можливо, занадто сильно порушили код (що ускладнює читання / розуміння, якщо вам потрібно переходити між функціями). Або це, або ви забуваєте свої особливі випадки / поводження з помилками!

Але я не вважаю корисним встановити абсолютне правило, оскільки завжди будуть дійсні винятки / причини, щоб відхилитися від правила:

• Однорядкова функція аксесуара, яка виконує тип типу, очевидно прийнятна в деяких ситуаціях.
• Є кілька дуже коротких, але корисних функцій (наприклад, своп, як згадував невідомий користувач), для якого явно потрібно менше 5 рядків. Не велика справа, кілька функцій 3 рядків не завдають шкоди вашій кодовій базі.
• Функція 100 рядків, яка є однією великою заявою комутатора, може бути прийнятною, якщо буде дуже зрозуміло, що робиться. Цей код може бути концептуально дуже простим, навіть якщо для опису різних випадків потрібно багато рядків. Іноді пропонується переробити це в окремі класи та реалізувати за допомогою успадкування / поліморфізму, але IMHO це забирає OOP занадто далеко - я б краще мати лише одне велике 40-річне перемикання, ніж 40 нових класів для вирішення, крім того до оператора 40-ти перемикачів для їх створення.
• Складна функція може мати велику кількість змінних стану, які стануть дуже безладними, якщо вони передаються між різними функціями як параметри. У цьому випадку ви можете обґрунтувати аргумент, що код простіший і простіший у дотриманні, якщо ви тримаєте все в одній великій функції (хоча, як Марк справедливо зазначає, це також може стати кандидатом для перетворення в клас, щоб інкапсулювати обидві логіки і держава).
• Іноді менші або більші функції мають переваги у виконанні (можливо, через вкраплення чи причини JIT, як згадує Франк). Це дуже залежить від впровадження, але це може змінити значення - переконайтеся, що ви орієнтир!

Тому в основному використовуйте здоровий глузд , дотримуйтесь невеликих розмірів функцій у більшості випадків, але не будьте догматичними щодо цього, якщо у вас є справді вагомі причини зробити незвично велику функцію.

Хоча я погоджуюся з коментарями інших людей, коли вони сказали, що немає правильного правила щодо правильного номера LOC, я маю на обмірі, якщо ми оглянемось на проекти, які ми розглянули в минулому, і визначимо кожну функцію вище, скажімо, 150 рядків коду, я ' м здогадуючись, ми б дійшли до консенсусу, що 9 з 10 цих функцій порушують SRP (і, ймовірно, OCP також), мають занадто багато локальних змінних, занадто великий потік управління і їх, як правило, важко читати та підтримувати.

Тому, хоча LOC не може бути прямим показником поганого коду, це, безумовно, гідний непрямий показник того, що певна функція може бути записана краще.

У своїй команді я потрапив у позицію ведучого, і з будь-якої причини люди, здається, мене слухають. Я, як правило, вирішив сказати команді, що, хоча немає абсолютного обмеження, будь-яка функція більше 50 рядків коду повинна як мінімум підняти червоний прапор під час перегляду коду, так що ми ще раз поглянемо на це і повторно оцінимо його за складність та порушення SRP / OCP. Після цього другого погляду ми можемо залишити його в спокої або можемо змінити, але принаймні це змушує людей замислюватися над цими речами.

Я вступив у проект, який не піклувався про правила кодування. Коли я заглядаю в код, я іноді знаходжу класи з більш ніж 6000 рядків коду і менше 10 методів. Це сценарій жахів, коли вам доведеться виправляти помилки.

Загальне правило того, наскільки максимум має бути метод, іноді не так добре. Мені подобається правило Роберта К. Мартіна (дядько Боб): "Методи повинні бути маленькими, меншими за малі". Я намагаюся використовувати це правило весь час. Я намагаюся зберегти свої методи простими і маленькими, пояснюючи, що мій метод робить лише одне і нічого більше.

Мова не про кількість рядків, це про SRP. Відповідно до цього принципу, ваш метод повинен робити одне і лише одне.

Якщо ваш метод робить це І це, і це АБО, що => це, ймовірно, робить багато. Спробуйте переглянути цей метод і проаналізувати: "тут я отримую ці дані, сортую їх і отримую потрібні мені елементи" і "тут я обробляю ці елементи" і "тут я нарешті їх об'єдную, щоб отримати результат". Ці "блоки" мають бути відновлені до інших методів.

Якщо ви просто слідуєте SRP, більшість ваших методів буде малою і з чітким наміром.

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

Можливо, у вас є комутатор на 400 ліній методом (часто трапляється в телекомунікаціях), і це все одно однозначна відповідальність, і це цілком нормально.

Це серйозно залежить від того , що насправді на це питання немає надійної відповіді, оскільки мова, якою ви працюєте, має значення, п'ять-п'ятнадцять рядків, згаданих у цій відповіді, можуть працювати для C # або Java, але в інших мовах це не дає вам багато з чим працювати. Так само, залежно від домену, в якому ви працюєте, ви можете виявити, що ви пишете значення параметрів коду у великій структурі даних. З деякими структурами даних у вас можуть бути десятки елементів, які вам потрібно встановити, якщо ви повинні розбити речі на окремі функції лише тому, що ваша функція працює довго?

Як зазначали інші, найкращим правилом є те, що функція повинна бути єдиною логічною сутністю, яка обробляє одну задачу. Якщо ви спробуєте застосувати драконівські правила, які говорять про те, що функції не можуть бути довшими n рядків, і ви зробите це значення занадто малим, ваш код стане важче читати, оскільки розробники намагаються використовувати химерні трюки, щоб обійти правило. Так само, якщо ви встановите його занадто високо, це буде проблемою, яка може призвести до поганого коду, хоча і лінь. Ваша найкраща ставка - просто провести перегляд коду, щоб переконатися, що функції впораються з одним завданням і залишити його на цьому.

Я думаю, що одна з проблем тут полягає в тому, що довжина функції нічого не говорить про її складність. LOC (рядки коду) - поганий інструмент для вимірювання чого-небудь.

Метод не повинен бути надмірно складним, але є сценарії, коли довгий метод можна легко підтримувати. Зауважимо, що наступний приклад не говорить про те, що його не можна розділити на методи, лише те, що методи не змінять ремонтопридатність.

наприклад, обробник вхідних даних може мати велику заяву комутатора, а потім простий код на кожний випадок. У мене є такий код - управління вхідними даними з каналу. 70 (!) Цифрово кодованих обробників. Тепер можна сказати "використовувати константи" - так, за винятком того, що API їх не надає, і мені подобається залишатися поруч із "джерелом" тут. Методи? Звичайно - просто, на жаль, всі вони мають справу з тими ж двома величезними структурами. Немає користі в їх розбитті, за винятком того, що, можливо, є більше методів (читабельності). Код по суті не складний - один перемикач, залежно від поля. Тоді кожен випадок має блок, який аналізує x елементи даних і публікує їх. Нічого кошмару на технічне обслуговування. Існує одне повторення "якщо умова, яка визначає, чи є у поля дані (pField = pFields [x], якщо pField-> IsSet () {blabla}) - стільки ж для кожного поля.

Замініть це набагато меншою рутиною, що містить вкладений цикл і безліч реальних операторів комутації, і величезний метод може бути простішим в обслуговуванні, ніж один менший.

Тож, вибачте, LOC - це не дуже вдалий показник. Якщо що-небудь, то слід використовувати точки складності / рішення.

Я просто накину ще одну цитату.

Програми повинні бути написані для того, щоб люди могли читати, і лише випадково для машин для виконання

- Гарольд Абелсон

Дуже неймовірно, що функції, які зростають до 100-200, дотримуються цього правила

Я був у цій шаленій ракетці, так чи інакше, з 1970 року.

За весь цей час, за двома винятками, до яких я дістанусь за мить, я ніколи не бачив добре розробленого "розпорядку" (методу, процедури, функції, підпрограми і будь-якого іншого), який НЕОБХІДНО мати більше однієї друкованої сторінки ( близько 60 рядків) завдовжки. Переважна більшість із них були зовсім небагато, порядку 10-20 рядків.

Однак я бачив багато "коду потоку свідомості", написаного людьми, які, очевидно, ніколи не чули про модуляризацію.

Два винятки були дуже особливими випадками. Один з них - це клас випадків винятків, який я збиваю разом: великі автомати з обмеженим станом, реалізовані як великі некрасиві заяви переключення, як правило, тому що немає більш чіткого способу їх реалізації. Ці речі зазвичай відображаються в автоматизованому тестовому обладнанні, аналізуючи журнали даних із тестуваного пристрою.

Іншим було рутинне фотонне торпедо з гри "Матушек-Рейнольдс-МакГегеарті-Коен" STARTRK, написане в CDC 6600 FORTRAN IV. Він повинен був проаналізувати командний рядок, а потім імітувати політ кожної торпеди з збуреннями, перевірити взаємодію між торпедою та кожним видом речі, в яку вона могла б потрапити, і о, до речі, імітувати рекурсію, щоб зробити 8-ти напрямну зв'язок на ланцюгах нове від торпедування зірки, яка була поруч з іншими зірками.

Якщо я знайду довгий метод - я можу поставити під сумнів, що цей метод не перевірений належним чином, або в більшості випадків він не має одиничного тесту. Якщо ви почнете робити TDD, ви ніколи не будуватимете 100-рядкових методів з 25 різними обов'язками та 5 вкладеними петлями. Тести зобов'язують вас постійно перетворювати ваш безлад і писати чистий код дядька Боб.

Немає абсолютних правил щодо тривалості методу, але корисні такі правила:

1. Основна мета функції - знайти повернене значення. Іншої причини для його існування немає. Після того, як ця причина заповнена, жоден інший код до неї не слід вставляти. Це обов'язково зберігає функції невеликими. Викликати інші функції слід, лише якщо це полегшує пошук повернутого значення.
2. З іншого боку, інтерфейси повинні бути невеликими. Це означає, що ви або маєте велику кількість класів, або у вас є великі функції - один з двох відбудеться, як тільки ви почнете мати достатньо коду, щоб зробити щось істотне. Великі програми можуть мати і те, і інше.

Чи автори означають одне і те ж саме під "функцією" та "рутиною"? Як правило, коли я кажу "функція", я маю на увазі підпрограму / операцію, яка повертає значення та "процедуру" для тієї, яка не є (і виклик якої стає єдиним твердженням). Це не є загальною відмінністю у реальному світі в цілому, але я бачив це в текстах користувачів.

Так чи інакше, правильної відповіді на це немає. Перевага до того чи іншого (якщо взагалі є перевага) - це те, що я б очікував сильно відрізнятися між мовами, проектами та організаціями; так само, як це є з усіма кодовими умовами.

Я хотів би додати, що твердження про "довгі операції не є більш схильними до помилок, ніж короткі операції" - це неправда. На додаток до того, що більше коду дорівнює більшому потенційному простору помилок, сліпо очевидно, що розбиття коду на сегменти дозволить уникнути помилок і легше їх знайти. Інакше взагалі не було б приводу розбивати код на частини, окрім повторення. Але це, мабуть, справедливо лише в тому випадку, якщо згадані сегменти достатньо добре задокументовані, що ви можете визначити результати операційного виклику, не читаючи або відстежуючи фактичний код (проект-за контрактом на основі специфікацій, а не конкретної залежності між областями коду).

Крім того, якщо ви хочете, щоб довші операції працювали добре, ви можете прийняти більш жорсткі конвенції про коди для їх підтримки. Закидання оператора повернення в середині операції може бути непоганим для короткої операції, але при більш тривалих операціях це може створити великий розділ коду, який умовний, але не очевидно, умовний для швидкого зчитування (лише для одного прикладу).

Тож я б подумав, що тип стилю, який є меншою ймовірністю, є кошмаром, наповненим помилками, значною мірою залежатиме від того, яких умов ви дотримуєтесь у решті коду. :)

IMHO, вам не доведеться використовувати смугу прокрутки, щоб прочитати свою функцію. Як тільки вам потрібно перенести смугу прокрутки, знадобиться ще кілька разів, щоб зрозуміти, як працює функція.

Відповідно, це залежить від звичного середовища програмування вашої команди (дозвіл екрана, редактор, розмір шрифту тощо). У 80-х це було 25 рядків і 80 стовпців. Зараз у своєму редакторі я показую майже 50 рядків. Кількість стовпців, що відображаються, не змінювалася, оскільки я розділив екран на два, щоб відображати два файли часом.

Якщо коротко, це залежить від налаштування ваших колег.

Я думаю , що відповідь TomTom наблизився до того, як я до цього ставлюсь.

Все більше і більше я переживаю цикломатичну складність, а не лінії.

Зазвичай я прагну не більше однієї структури управління за методом, за винятком, однак, скільки циклів потрібно для обробки багатовимірного масиву.

Іноді мені здається, що я розміщую однорядний ifs у випадках переключення, тому що чомусь це випадки, коли їх розбиття перешкоджає, ніж допомагає.

Зауважте, що я не рахую логіку охорони проти цієї межі.

В OOP всі речі об’єктують і є ці особливості:

1. Поліморфізм
2. Абстракція
3. Спадщина

Якщо ви дотримуєтесь цих правил, то ваші методи, як правило, невеликі, але не існує жодного правила для малих або дуже малих (наприклад, 2-3 рядкових) правил. Перевагою малого методу (малої одиниці, наприклад, методу чи функції) є:

1. краще читабельний
2. підтримувати краще
3. краще виправити помилку
4. змінюється краще