Чи існує оптимальна кількість рядків коду на функцію? [зачинено]

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

Це змушує мене замислитися: чи існує оптимальна кількість LOC на функцію? Якщо так, що це таке, і чи відхиляється він між мовами?

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

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

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

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

Немає жодної.

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

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

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

За замовчуванням браузер не дуже великий. Ви можете помістити 5 або 6 рядків, перш ніж вам потрібно буде починати прокручування. Прокручування, звичайно, трохи дратує.

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

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

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

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

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

Відповідь звичайно 42 .

Важливо зауважити: жодна фунція ніколи не може порушити СРП , або вам доведеться зіткнутися зі спанішкою .

Кілька підказок, як зменшити кількість рядків:

• Чи є коментарі, що позначають окремі розділи? Ці розділи повинні бути функціями.
• Чи є ланцюги if-else або перемикають заяви поза фабрикою / будівельником? Можливо, ваш дизайн потребує кращих моделей дизайну, які допоможуть вам розділити обов'язки.
• Чи легко перевірити свої функції? Зробіть легко тестувати свої функції, вони розпадуться.
• Це складний і просто немає землі в сигті (1000 лінійних монстрів)? Робіть металобрухт - це рефактор, і не економте його в надії отримати освіту про обов'язки кодексів.

Ось декілька підказок:

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

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

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

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

• Якщо вам потрібно робити нотатки під час читання функції, це занадто довго.

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