Скільки рядків у класі занадто багато на Java? [зачинено]

Як ви вважаєте, яке корисне правило: скільки рядків коду занадто багато для одного класу на Java?

Щоб було зрозуміло, я знаю, що кількість рядків навіть не наближається до реального стандарту, який слід використовувати для того, що має бути в певному класі, а що не повинно. Заняття повинні бути розроблені відповідно до належних філософій ООП (інкапсуляція тощо). Однак це правило може стати корисною відправною точкою для міркувань про рефакторинг (тобто "Хммм, у цього класу є> n рядків коду; це, мабуть, нечитабельно і виконує хитру роботу з інкапсуляції, тому я, можливо, захочу побачити, чи варто бути відновленим в якийсь момент ").

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

Ось пов'язане, не повторюване запитання про рядки на функцію .

Кілька цікавих показників:

            junit fitnesse testNG tam jdepend ant tomcat
            ----- -------- ------ --- ------- --- ------
макс 500 498 1450 355 668 2168 5457
середнє 64,0 77,6 62,7 95,3 128,8 215,9 261,6
хв 4 6 4 10 20 3 12
сигма 75 76 110 78 129 261 369
файли 90 632 1152 69 55 954 1468
всього рядків 5756 49063 72273 6575 7085 206001 384026

Я використовую FitNesse як орієнтир, тому що мені було багато спільного з його написанням. У FitNesse середній клас становить 77 рядків. Жоден не перевищує 498 рядків. А стандартне відхилення - 76 ліній. Це означає, що переважна більшість класів становить менше 150 рядків. Навіть у Tomcat, у якого один клас перевищує 5000 ліній, у більшості класів менше 500 рядків.

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

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

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

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

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

• Заповітність
• Згуртованість
• Зчеплення
• Зрозумілість

Заняття з великою кількістю рядків в них, швидше за все, будуть порушувати всі ці принципи.

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

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

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

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

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

Ще одна річ, яку ви можете подивитися - це кількість публічних функцій у класі. Це також може бути попереджувальним знаком.

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

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

Щодо фізичних обмежень, які ви можете мати (джерело: Формат файлу класу Java5 ):

• 65 536 констант, застосованих інтерфейсів, полів, методів та атрибутів - кожен. ПРИМІТКА. У вас буде нестабільне місце, перш ніж вичерпаєте будь-який з інших елементів. ПРИМІТКА 2: атрибути є файлами файлів класу - не плутати з маркерами "@Attribute" (тобто інформація про налагодження та байт-код зберігаються як окремі атрибути методу).
• Кожен метод може бути 4 Гб (32 біт) згенерованого байтового коду. ПРИМІТКА: Версії Java до 1.5 могли мати лише 64 КБ (16 біт) згенерованого байтового коду для кожного методу.

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

Правильна відповідь - 42. Просто жартую.
Насправді максимальний рекомендований рядок для класу - 2000 рядків.

"Конвенції Java-коду" з 1999 р. Заявляють це так:
Файли довші ніж 2000 рядків громіздкі і їх слід уникати.

Дотримуючись конвенцій кодування Sun / Oracle з часу винайдення Java, я визнав це правильним принципом у рядках кожного класу розумним. 99% вашого Java-коду має відповідати ... І якщо він перевищує 2000, просто поставте TODO вгорі, кажучи, що клас потребує роботи.

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

http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141855.html#3043

Чистий код:

Заняття повинні бути невеликими!

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

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

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

Тоді:

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

Ви отримаєте клас керованого розміру.

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

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

Спробуйте використовувати кращий показник.

Один із прикладів - метрика ABC . Це скоріше міра того, скільки роботи виконується кодом, ніж скільки коду.

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