Сколько строк в классе слишком много в Java? [закрыто]


74

По вашему опыту, какое полезное практическое правило для того, сколько строк кода слишком много для одного класса в Java?

Чтобы было ясно, я знаю, что количество строк даже близко не соответствует реальному стандарту, который следует использовать для того, что должно быть в определенном классе, а что нет. Классы должны разрабатываться в соответствии с надлежащими принципами ООП (инкапсуляция и т. Д.). Тем не менее, практическое правило может обеспечить полезную отправную точку для соображений рефакторинга (т. Е. «Хммм, этот класс имеет> n строк кода; он, вероятно, не читается и выполняет паршивую работу по инкапсуляции, поэтому я мог бы захотеть посмотреть, стоит ли быть рефакторингом в какой-то момент ").

С другой стороны, возможно, вы сталкивались с примерами очень больших классов, которые все еще хорошо выполняли дизайн ООП и были удобочитаемыми и поддерживаемыми, несмотря на их длину?

Вот связанный, не повторяющийся вопрос о строках для каждой функции .


4
Я видел классы с более чем тысячей строк, я не думаю, что есть такая вещь, как «слишком много».
Махмуд Хоссам

5
Это слишком много, когда он больше не будет компилироваться. Серьезно, это слишком много, когда класс делает слишком много разных вещей.
Берин Лорич

20
Практическое правило превращается в максимум, который превращается в политику, которая превращается в разногласие. Избегайте счисления. Подсчет и измерение - не идеальный способ установить, правильно ли распределены обязанности.
S.Lott

7
Примерно столько же, сколько правильное количество дюймов для куска строки.
Мэтт

6
Вопрос с 30 голосами, просмотрено ~ 24k раз, 10 ответов (коллективно) ~ 75 голосов. "закрыто как основанное на мнении" Добро пожаловать на стек обмена :) Что-то должно измениться в культуре SE ...
JB.

Ответы:


79

Некоторые интересные метрики:

            тест на пригодность для юниоров
            ----- -------- ------ --- ------- --- ------
макс 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 строк в качестве хорошего ориентира, чтобы оставаться ниже.


9
Если у класса есть только одна ответственность, шансы превышения 200-500 строк довольно малы. Те, которые, как правило, имеют «внутренние классы», чтобы справляться с другими связанными обязанностями. Например, линейный класс Tomcat 5000+ действительно может быть одним основным классом с дюжиной внутренних классов. Это не является необычным в Java, где у вас есть обработчики запросов и тому подобное.
Берин Лорич

4
как эти показатели получены, на самом деле? просто хочу знать
Снаđошƒаӽ

1
Обычно я больше склоняюсь к этому ответу по связанному вопросу, связанному с функциями: programmers.stackexchange.com/a/9452/100669 LOC является неуместным, за исключением, как, возможно, чрезвычайно общего практического правила, чтобы просто начать задаваться вопросом, можете ли вы быть в состоянии сломать вещи дальше. И я согласен с вещами вложенных классов. Тем не менее, 500, вероятно, ближе к общему предупреждению.
Panzercrisis

@ Sнаđошƒаӽ github.com/AlDanial/cloc
firephil

32

Для меня строки кода не имеют значения в этом контексте. Все дело в количестве разных причин, по которым я бы пришел в этот класс, чтобы изменить его.

Если бы я пришел в этот класс, когда хочу изменить правила проверки личности, я не хочу приходить в тот же класс, чтобы изменить правила проверки ордера, и при этом я не хочу приходить сюда, чтобы изменить место, где я Персонаж

Тем не менее, если вы стремитесь к этому, то вы редко найдете классы более 200 строк. Они произойдут по уважительным причинам, но они будут редкими. Так что, если вы ищете метрику красного флага, то это не плохое место для начала; но сделайте это руководством, а не правилом.


200 кажется правильным как очень грубое предположение. Как вы говорите, не то, о чем вы беспокоитесь в первую очередь.
Стив

Ничего особенного в Java нет: при подсчете LOC я бы игнорировал методы получения / установки.
MrFox

1
@MrFox: я не согласен. Если в вашем классе достаточно геттеров и сеттеров, чтобы искажать данные LOC, то это считается "не слишком ли много делает этот класс?" вопрос. Тем не менее, в качестве компромисса я бы хотел, чтобы геттеры / сеттеры NetBean были менее чем на 1 линию / линию из уважения к чрезмерной котельной плите, которую имеют такие методы.
Брайан

23

Извините, но я очень удивлен, что во многих ответах говорится, что это "не имеет значения". Это очень много значит, сколько строк в классе. Почему? Учитывайте эти принципы при написании хорошего Java-кода ...

  • способность быть свидетелем в суде
  • когезия
  • Связь
  • Понятность

Классы с большим количеством строк, скорее всего, будут нарушать все эти принципы.

Для тех, кто заявил, что это «не имеет большого значения» ... насколько весело было вам пытаться понять класс, в котором более 5000 строк? Или изменить это? Если вы говорите, что это весело, у вас странная близость к боли ...

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

Мои комментарии основаны на чтении и изучении таких авторов, как Мартин Фаулер, Джошуа Блох и Миско Хевери. Они являются отличными ресурсами для консультации по написанию хорошего Java-кода.

Подарите следующему парню (которым вы могли бы стать через пару лет) услугу и постарайтесь написать классы, в которых меньше, а не больше строк.


Я думаю, что все согласны с тем, что 5000+ обычно не является хорошим знаком (не считая вложенных классов), но они чувствуют, что это скорее побочный эффект или что-то, чем реальная проблема. Конечно, некоторые люди слишком многословны и используют чрезмерное количество строк просто для объявления и инициализации переменных и тому подобного - и им нужно это остановить. Это делает его менее читабельным. Но если это относится к структуре классов, проблема не в самом LOC; это факт, что кто-то просто не очень хорошо разбивает вещи с самого начала, и LOC является побочным эффектом этого.
Panzercrisis

2
Дело в том, что у класса должна быть высокая сплоченность и четкая ответственность, что означает, что классы обычно не становятся такими большими. Но если класс хорошо спроектирован, но все еще содержит более 5000 строк кода, он не поможет никому разбить его на несколько более мелких тесно связанных классов.
JacquesB

12

Это зависит от сложности, а не от количества строк. Я написал большие глупые подпрограммы, которые были просты для понимания, и которые делали точно одно и делали это хорошо, но продолжались сотни строк. Я написал довольно короткие функции, которые было трудно понять (и отлаживать).

Еще одна вещь, на которую вы можете обратить внимание, это количество открытых функций в классе. Это также может быть предупреждающим знаком.

У меня нет хороших подсчетов, но я бы посоветовал взглянуть на приличный код, который делает полезные вещи в вашем магазине, и основывать его на этом. Конечно, вы должны смотреть на самые длинные классы и самые большие API.


7
+1: не измеряй глупые вещи, как линии. Цикломатическая сложность и количество признаков (количество методов) имеют больше смысла в линиях.
S.Lott

2
и да и нет. Чрезмерное количество строк часто является признаком плохого дизайна и, следовательно, красным флагом, который класс, вероятно, нуждается в рефакторинге.
jwenting

1
@jwenting Да, вот к чему я клоню. Я знаю много строк! = Нужно провести рефакторинг, но почти все классы, с которыми я работаю, действительно нуждаются в рефакторинге из-за плохого дизайна, имеют много строк.
Майкл МакГоуэн

5

Слишком много строк кода, если класс делает слишком много разных вещей. По сути, если вы следуете принципу Единой Ответственности для классов, существует предел того, насколько большой будет расти класс.

Что касается физических ограничений, которые вы можете иметь (источник: файл класса формата Java5 ):

  • 65 536 констант, примененные интерфейсы, поля, методы и атрибуты - каждая. ПРИМЕЧАНИЕ: вам не хватит места, прежде чем вы исчерпаете любой из других предметов. ПРИМЕЧАНИЕ 2: атрибуты являются конструкциями файлов классов - их не следует путать с маркерами «@Attribute» (т. Е. Отладочная информация и байтовый код хранятся как отдельные атрибуты для метода).
  • Каждый метод может быть 4 ГБ (32 бита) сгенерированного байтового кода. ПРИМЕЧАНИЕ: версии Java до 1.5 могут иметь только 64 КБ (16 бит) сгенерированного байтового кода для каждого метода.

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


1
+1 за одиночную ответственность :) @ Берин, вы реализуете это строго в своем программном обеспечении?
Адитья П

Да. Хитрость заключается в том, чтобы разделить обязанности таким образом, чтобы это имело смысл.
Берин Лорич

ах, старая добрая граница 64КБ. Хороший тест lithmus , чтобы увидеть ли ваши JSPs слишком сложны, так как они переводятся на один метод с большим количеством Println заявлений для всех ваших статических HTML :)
jwenting

Что касается Java 5, они увеличили его до 4 ГБ. Не беспокойтесь там сейчас.
Берин Лорич

5

Правильный ответ 42. Шучу.
На самом деле, максимальное рекомендуемое количество строк в классе - 2000 строк.

«Соглашения по Java-коду» с 1999 года утверждают это так:
файлы длиной более 2000 строк громоздки и их следует избегать.

Следуя соглашениям Sun / Oracle Coding со времени изобретения Java, я нашел разумное правило для строк в классе. 99% вашего Java-кода должны соответствовать ... А если он превышает 2000, просто поместите TODO на вершине, говоря, что класс нуждается в работе.

Хуже всего то, что программисты создают слишком много крошечных маленьких классов, в которых практически нет функциональности в каждом классе. Игнорируя рекомендацию «Favor Composition», программисты создают сотни наследующих классов, которые создают сложные объектные модели, которые намного хуже, чем проблема больших классов (которые, по крайней мере, обычно сохраняют функциональность с соответствующим именем класса).

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


На самом деле, большинство из них являются комментариями @LluisMartinez
Xtreme Biker

Я категорически не согласен с 2000 годом . Класс должен быть не длиннее 200 строк, исключая комментарии.
Николас

4

Чистый код:

Классы должны быть маленькими!

Первое правило классов - они должны быть маленькими. Второе правило классов заключается в том, что они должны быть меньше, чем это. Нет, мы не собираемся повторять один и тот же текст из главы «Функции». Но, как и в случае с функциями, меньшее является основным правилом, когда дело доходит до проектирования классов. Как и в случае с функциями, нашим непосредственным вопросом всегда является «Как мало?»

** С помощью функций мы измерили размер путем подсчета физических линий. С классами мы используем другую меру. Мы считаем обязанности. **

Название класса должно описывать, какие обязанности он выполняет. На самом деле, наименование - это, вероятно, первый способ помочь определить размер класса. Если мы не можем получить краткое имя для класса, то оно, вероятно, слишком велико. Чем более двусмысленно имя класса, тем более вероятно, что у него слишком много обязанностей. Например, имена классов, включая такие слова, как Processor или Manager или Super, часто намекают на неудачное объединение обязанностей.

Затем:

  • Просто убедитесь, что ваши методы делают только одно.
  • Затем убедитесь, что у класса не слишком много обязанностей.

В итоге вы получите класс с управляемым размером.


если Clean Codeв верхней части вашего ответа упоминается книга Роберта К. Мартина (что она делает!), то я должен сказать вам, и у меня есть общее; эта книга и привела меня к этому вопросу. Я думаю, что этот ответ говорит сам за себя
Снаđошƒаӽ

2

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

Это совсем другой разговор, но частные методы и поля для меня меньше пахнут, так что, если они вносят большой вклад в число строк, я, возможно, не так обеспокоен. По крайней мере, это показывает, что, вероятно, нет какого-то божьего контроллера, манипулирующего объектом издалека, что является довольно сложной проблемой проектирования.


2

Попробуйте использовать лучший показатель.

Одним из примеров является ABC Metric . Это скорее показатель того, сколько работы выполняется кодом, чем количество кода.


1

Любая строка, попадающая в проблемную область вашего класса, написанная вне класса, - это одна строка слишком мало и одна слишком много в классе, где она живет. Думайте о классе как о теме. Вы должны покрыть это. Идеально, как можно более кратко, идеально, но если он занимает 500 строк, он занимает 500 строк. Если 100 из этих строк охватывают другую тему, они принадлежат где-то еще. Разбивка на более мелкие субдомены внутри класса как внутренних классов имеет смысл, но я бы определил те, которые находятся вне класса, если бы они использовались где-то еще.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.