У який момент / діапазон файл коду завеликий?

Я знаходжу безліч файлів з 2-3k рядків, і мені не дуже здається, що вони повинні бути такими великими.

Які хороші критерії об'єктивно називати файл вихідного коду "занадто великим"? Чи існує така річ, як максимальна кількість рядків, у яких має бути файл вихідного коду?

Як ідеальну модель я використовую такі критерії (з аналогічним обґрунтуванням того, що запропонував Мартін Беккет, тобто думати з точки зору логічної структури, а не з точки зору рядків коду):

Правило 1

Один клас на файл (у C ++: один клас -> один заголовок та один файл реалізації).

Правило 2

Сім вважається кількістю предметів, які наш мозок може спостерігати одночасно, не плутаючись. Вище 7 нам важко тримати огляд того, що ми бачимо. Тому: у кожному класі не повинно бути більше 7-10 методів. Клас, який має більше 10 методів, ймовірно, занадто складний, і вам слід спробувати розділити його. Розщеплення - це дуже ефективний метод, оскільки щоразу, коли ви розділяєте клас, ви зменшуєте складність кожного окремого класу хоча б на 2 рази.

Правило 3

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

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

Збираючи разом ці дуже приблизні оцінки:

• Максимум один клас на вихідний файл.
• Максимум 10 публічних методів на заняття.
• Максимум 10 приватних методів на клас.
• Максимум 100 рядків за методом.

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

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

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

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

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

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

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

Але коли це станеться, час це розділити.

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

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

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

Отже, поки коефіцієнт виправлення помилок (відношення виправлення помилок до всіх комісій) низький для великих файлів, ситуація є терпимою. Будь ласка, спробуйте git logце і перегляньте, скільки комісій пов'язано з помилками. Або використовувати інструмент, який може автоматично аналізувати та візуалізувати його, наприклад, Softagram .

Розглянемо це Metaphor. Що стосується довжини коду, я думаю, ми повинні врахувати наступне:

The Cat in The Hat (50 pp.)

і

Lord of The Rings (1,178 pp.)

У цьому немає нічого поганого Lord of the Rings. Це казкова книга. The Cat in the Hatтакож чудова книга. І те й інше можна зрозуміти 5-річним, але лише один краще підходить за змістом.

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

Більшість із нас не пише код збірки . Але корінь нашого коду - це збірка. Пошук по збірці 10000 ліній складніше, ніж 10000 рядків пітона, якщо це зроблено правильно.

Але деяка робота вимагає написання від 500 до 1000 рядків. Нашою метою з кодом має бути написання 300 рядків чистого коду.

Як розробники ми хочемо написати «Володар кілець». Поки ми не отримали помилку та побажання, ми писали "Кіт у капелюсі". Не робіть кодування мірою его. Просто змусьте справи працювати просто.

Розробники не хочуть документувати код (я люблю документований код особисто, я не такий егоїстичний). Тому не пишіть код, який тільки ви можете зрозуміти / прочитати. Написати Cat in the Hatкод.

Ми всі знаємо, що ви - JRR Tolken (в голові). Пам'ятайте, що вам не доведеться нічого доказувати за допомогою безкоштовного коду.

Ще одна причина метафори.

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

Усі люблять ребалінг.

-> Сказав ніхто ніколи!

TL; DR Зосередження уваги на читанні. Розкладіть свій код і помічник по декількох рядках і файлах стільки, скільки зможете. Не кидайте 8 або 9 класів в один файл, це робить код важким для читання і складніше в обслуговуванні. Якщо у вас великий код умови або цикл, подумайте про зміну їх на Lambdas, якщо мова їх підтримує. Функції утиліт слід вважати чудовим способом підвищення читабельності коду. Уникайте важких гнізд.