Коли функція занадто довга? [зачинено]

35 рядків, 55 рядків, 100 рядків, 300 рядків? Коли ви повинні почати розбивати його на частини? Я запитую, бо у мене функція з 60 рядків (включаючи коментарі) і думала про її розрив.

long_function(){ ... }

в:

small_function_1(){...}
small_function_2(){...}
small_function_3(){...}

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

Коли ви розділите функцію на більш дрібні? Чому?

1. Методи повинні робити лише одну логічну річ (подумати про функціональність)
2. Ви повинні мати можливість пояснити метод в одному реченні
3. Він повинен відповідати висоті вашого дисплея
4. Уникайте зайвих накладних витрат (коментарі, які вказують на очевидне ...)
5. Тестування одиниць легше для малих логічних функцій
6. Перевірте, чи можна частину функції використовувати повторно іншими класами чи методами
7. Уникайте надмірної міжкласової зв'язку
8. Уникайте глибоко вкладених структур управління

Дякую всім за відповіді , відредагуйте список та проголосуйте за правильну відповідь, яку я оберу;)

Я зараз переглядаю ці ідеї на увазі :)

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

Однак, "щось робити" все-таки може бути досить багато рядків, тому я не впевнений, що ряд рядків є правильним показником, який слід використовувати :)

Редагувати: Це єдиний рядок коду, який я надіслав по роботі на минулому тижні (щоб довести свою думку. Це не те, що я маю звичку :)) - Я, звичайно, не хотів би 50-60 цих поганих хлопців у моєму методі : D

return level4 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3) && (r.Level4 == (int)level4)).ToList() : level3 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3)).ToList() : level2 != null ? GetResources().Where(r => (r.Level2 == (int)level2)).ToList() : GetAllResourceList();

Ось список червоних прапорів (не в конкретному порядку), які можуть вказувати на те, що функція занадто довга:

1. Глибоко вкладені структури управління : наприклад, для-циклів 3 рівня глибокого або навіть просто 2 рівня глибиною з вкладеними операторами if, які мають складні умови.

2. Занадто багато параметрів, що визначають стан : Під параметром , що визначає стан , я маю на увазі параметр функції, який гарантує певний шлях виконання через функцію. Отримайте занадто багато параметрів цього типу, і у вас є комбінаторний вибудок шляхів виконання (це зазвичай відбувається в тандемі з №1).

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

4. Надмірна міжкласова сполука : ця відсутність належної інкапсуляції призводить до того, що функції стосуються інтимних характеристик інших класів, отже, подовжуючи їх.

5. Непотрібні накладні витрати : коментарі, які вказують на очевидні, глибоко вкладені класи, зайві getters та setters для приватних вкладених змінних класів, і незвично довгі назви функцій / змінних можуть створювати синтаксичний шум у відповідних функціях, що в кінцевому підсумку збільшить їх довжину.

6. Ваш масовий дисплей для розробників недостатньо великий, щоб його відображати . Насправді сьогодні екрани є досить великими, що функція, яка знаходиться десь поблизу від висоти, ймовірно, занадто довга. Але, якщо вона більша , це курильне пістолет, що щось не так.

7. Ви не можете відразу визначити мету роботи функції : Крім того, як тільки ви на самому справі робите визначити свою мету, якщо ви не можете підвести підсумок цієї мети в одному реченні або трапиться мати величезну головний біль, це повинно бути ключем.

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

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

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

Те, що ви насправді не хочете робити, - це копіювати та вставляти кожні 10 рядків своєї тривалої функції на короткі функції (як підказує ваш приклад).

Я погоджуюся, що функція повинна виконувати лише одне, але на якому рівні це одна річ.

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

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

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

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

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

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

Чому я можу порушити функцію:

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

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

Розмір приблизно за розміром екрана (тому займіться великим широким екраном та поверніть його ... :-)

Жарт убік, одна логічна річ на функцію.

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

/ Йохан

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

function build_address_list_for_zip($zip) {

    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

набагато приємніше:

function fetch_addresses_for_zip($zip) {
    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }
    return $addresses;
}

function build_address_list_for_zip($zip) {

    $addresses = fetch_addresses_for_zip($zip);

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

Цей підхід має дві переваги:

1. Кожен раз, коли вам потрібно отримати адреси для певного поштового коду, ви можете використовувати легко доступну функцію.

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

[З іншого боку (заперечу, я говорив вам про це, навіть під тортурами): Якщо ви багато читаєте про оптимізацію PHP, ви можете отримати ідею зберегти кількість функцій якомога меншим, оскільки виклик функції дуже, дуже дорого в PHP. Я не знаю про це, оскільки ніколи не робив жодних орієнтирів. У такому випадку вам, мабуть, було б краще не дотримуватися жодного з відповідей на ваше запитання, якщо заявка дуже "чутлива до продуктивності" ;-)]

Погляньте на цикломатику МакКейба, в якій він розбиває свій код на графік, де: «Кожен вузол у графі відповідає блоку коду в програмі, де потік є послідовним, а дуги відповідають гілкам, взятим у програмі. "

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

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

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

Ця відповідь дається рівнянням. Якщо r - кількість методів, що мінімізує MPE системи, а n - кількість блоків у системі, то рівняння дорівнює: r = sqrt (n)

І може бути показано, що це дає також кількість блоків для методу, яка також буде sqrt (n).

Майте на увазі, що ви можете закінчити повторний факторинг тільки заради повторного факторингу, що, можливо, зробить код більш нечитабельним, ніж це було в першу чергу.

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

Отже, моя власна мантра стала: якщо ви не можете придумати гідну назву функції / методу для фрагмента коду, який ви перенастроюєте, не турбуйтеся.

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

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

Ви впевнені, що там немає деталей, які були б корисні в іншому місці? Що це за функція?

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

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

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

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

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

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

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

Див . Оптимальний розмір класу для об'єктно-орієнтованого програмного забезпечення для подальшого обговорення.

Я раніше писав 500 лінійних функцій, однак це були просто великі заяви про перемикання для декодування та відповіді на повідомлення. Коли код для одного повідомлення став складнішим, ніж для одного if-then-else, я витяг його.

По суті, хоча функція складала 500 ліній, незалежно підтримувані регіони в середньому складали 5 ліній.

Я зазвичай використовую тестовий підхід до написання коду. У такому підході розмір функції часто пов'язаний із деталізацією ваших тестів.

Якщо ваш тест достатньо сфокусований, то це призведе до написання невеликої цілеспрямованої функції, щоб тест пройшов.

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

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

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

Кожен для циклу, якщо оператор тощо, тоді не розглядається як гілка методу виклику.

Кобертура для Java-коду (і я впевнений, що є інші інструменти для інших мов) обчислює кількість функцій if та ін. У функції для кожної функції та підсумовує її для "середньої циклічної складності".

Якщо функція / метод має лише три гілки, вона отримає три на цій метриці, що дуже добре.

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

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

Я підозрюю, що ви знайдете багато відповідей на це.

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

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

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

якщо припустити, що ви робите одне , тривалість буде залежати від:

• що ти робиш
• якою мовою ви користуєтесь
• скільки рівнів абстракції вам потрібно розібратися в коді

60 рядків може бути занадто довгим, або це може бути правильним. я підозрюю, що це може бути занадто довгим.

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

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

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