Вопрос по – Количество строк в классе хорошей практики [закрыто]

17

Я знаю, что нет правильного ответа на этот вопрос, я просто спрашиваю ваше мнение.

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

По вашему мнению, каково среднее число строк для класса, скажем, на Java (я не знаю, имеет ли отношение выбор языка к этому, но на всякий случай ...)

Хорошая практика подсчитывать сидячий час ??? Abdulsattar Mohammed
Связанный вопрос:stackoverflow.com/questions/2222831/when-is-a-class-too-long sleske

Ваш Ответ

12   ответов
5

Я сосредотачиваюсь на методах и стараюсь держать их ниже 20 строк кода. Длина класса в целом определяется принципом единой ответственности. Но я считаю, что это не абсолютная мера, потому что это зависит от уровня абстракции, поэтому где-то между 300 и 500 строками я начинаю просматривать код на предмет новой ответственности или извлечения абстракции.

30

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

В общем, я использую следующие правила:

  • < 300 lines: fine
  • 300 - 500 lines: reasonable
  • 500 - 1000 lines: maybe ok, but plan on refactoring
  • > 1000 lines: definitely refactor

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

0

Вы правы ... на это нет ответа. Вы не можете поместить "наилучшую практику" вниз как количество строк кода.

Тем не менее, в качестве руководства я часто использую то, что вижу на одной странице. Как только метод не помещается на одной странице, я начинаю думать, что я делаю что-то не так. Что касается всего класса, то, если я не смогу увидеть все заголовки метода / свойства на одной странице, то, возможно, мне нужно также начать разбивать это.

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

2

По моему опыту любой исходный файл более 1000 строк текста я начну хотеть разбить. В идеале методы должны уместиться на одном экране, если это возможно.

В последнее время я начал понимать, что удаление бесполезных комментариев может сильно помочь в этом. Я комментируюfar более экономно, чем 20 лет назад, когда я впервые начал программировать.

16

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

Если вы заинтересованы в измерениях LOC, цикломатических и других сложностей, я настоятельно рекомендую Source Monitor изhttp://www.campwoodsw.com, которая бесплатна, работает с основными языками, такими как Java & amp; C ++, и все отлично.

Я тоже рекомендуюsonar.codehaus.org для количества строк и сложности.
1

подсчет строк == подсчет бинов.

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

Взгляните на файл / функцию и подумайте, с ней все еще удобно работать или она становится громоздкой. Если вы сомневаетесь, обратитесь к со-разработчику (или, если вы проводите индивидуальное шоу, какой-то разработчик, не имеющий отношения к проекту), чтобы взглянуть и поговорить об этом.

Это действительно так:a look, Кто-то еще сразу получает дрейф кода или это закрытая книга для непосвященных? Этот быстрый взгляд говорит вам больше о читабельности фрагмента кода, чем когда-либо разработанные метрики строк. Это зависит от очень многих вещей. Язык, проблемная область, структура кода, рабочая среда, опыт. Что хорошо для одной функции в одном проекте, может быть непропорционально для другой.

Если вы находитесь в ситуации команды / проекта и не можете легко согласиться с этим "одним быстрым взглядом" подход, у вас естьsocial проблема, а не техническая. (Различия в стандартах качества и, возможно, сбой связи.) Наличие правил для длины файлов / функций не решит вашу проблему. Сидеть и говорить об этом за прохладным напитком (или кофе, в зависимости ...) - лучший выбор.

4

Достаточно маленький, чтобы выполнять только задачу, с которой он отвечает.

Достаточно большой, чтобы выполнить только задачу, с которой он отвечает.

Не больше, не меньше.

1

так это на несколько факторов. Сначала я проверяю свои утверждения If-Else-If. Если многие из них имеют одинаковые условия или приводят к запуску аналогичного кода, я пытаюсь реорганизовать это. Затем я смотрю на мои методы и переменные. В любом отдельном классе этот класс должен иметь одну основную функцию и только эту функцию. Если у него есть переменные и методы для другой области, рассмотрите возможность помещения их в свой класс. В любом случае, избегайте подсчета LOC по двум причинам:

1) Это плохой показатель. Если вы считаете LOC, вы считаете не только длинные строки, но и строки, которые являются пробелами и используются для комментариев, как если бы они были одинаковыми. Вы можете избежать этого, но в то же время вы по-прежнему одинаково считаете маленькие и длинные строки.

2) Это вводит в заблуждение. Читаемость не является просто функцией LOC. Класс может быть легко читаемым, но если у вас есть счетчик LOC, который он нарушает, вы усердно работаете над тем, чтобы выжать из него столько строк, сколько сможете. Вы можете даже сделать код менее читабельным. Если вы берете LOC для назначения переменных, а затем используете их при вызове метода, это более читабельно, чем вызов назначений этих переменных непосредственно в самом вызове метода. Лучше иметь 5 строк читаемого кода, чем сжимать его в 1 строку нечитаемого кода.

Вместо этого я рассмотрю глубину кода и длину строки. Это лучшие показатели, потому что они говорят вам две вещи. Во-первых, вложенная глубина говорит вам о необходимости рефакторинга вашей логики. Если вы смотрите на операторы If или циклы, вложенные более чем в 2, серьезно подумайте о рефакторинге. Рассмотрите возможность рефакторинга, если у вас более одного уровня вложенности. Во-вторых, если строка длинная, она обычно очень нечитаема. Попробуйте выделить эту строку на несколько более читаемых строк. Это может нарушить ваш предел LOC, если он у вас есть, но на самом деле улучшает читабельность.

1

Краткий ответ: менее 250 строк.

Короче ответ: му.

Более длинный ответ: код читаем и краток? Есть ли у класса единственная ответственность? Код повторяется?

0

Строки кода гораздо больше о многословности, чем любая другая вещь. В проекте, который я сейчас работаю, у нас есть несколько файлов с более чем 1000 LOC. Но если вы удалите комментарии, их, вероятно, останется около 300 или даже меньше. Если вы измените объявления, как

int someInt;
int someOtherInt;

до одной строки файл будет еще короче.

Однако, если вы не многословны и у вас все еще есть большой файл, вам, вероятно, придется подумать о рефакторинге.

у вас есть более двух строк комментариев на строку кода!?! возможно, вам следует рассмотреть возможность рефакторинга ваших комментариев.
Мы используем док. Комментарии. Некоторые классы включают примеры использования в этих комментариях.
9

От Эрика Рэймонда "Искусство программирования Unix"

In nonmathematical terms, Hatton's empirical results imply a sweet spot between 200 and 400 logical lines of code that minimizes probable defect density, all other factors (such as programmer skill) being equal. This size is independent of the language being used — an observation which strongly reinforces the advice given elsewhere in this book to program with the most powerful languages and tools you can. Beware of taking these numbers too literally however. Methods for counting lines of code vary considerably according to what the analyst considers a logical line, and other biases (such as whether comments are stripped). Hatton himself suggests as a rule of thumb a 2x conversion between logical and physical lines, suggesting an optimal range of 400–800 physical lines.

Взято изВот

8

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

Это слишком просто, даже при стандартизированном формате кода, чтобы строки кода не могли быть отсоединены от реальной сложности класса.

Изменить: см.этот вопрос для списка инструментов цикломатической сложности.

Цикломатическая сложность является формальным способом измерения сложности, и в то же время она действительно проста в использовании. Понравился этот ответ.
Интересный инструмент; Я этого не видел. В идеале это будет интегрировано с моей IDE, но ... ну, хорошо.
он имеет синтаксис командной строки, поэтому я уверен, что создание оболочки не так уж сложно. Savvas Dalkitsis
Мне нравится этот ответ. С помощью быстрого поиска в Google я нашел инструмент, который измеряет это на Java. Это называется PMDpmd.sourceforge.net Savvas Dalkitsis

Похожие вопросы