Я знаю, что нет правильного ответа на этот вопрос, я просто прошу вашего мнения.
Я знаю, что создание файлов класса HUGE с тысячами строк кода не является хорошей практикой, так как это трудно поддерживать, а также обычно означает, что вам следует, вероятно, рассмотреть вашу программную логику.
По вашему мнению, какое среднее количество строк для класса допустимо говорить на Java (я не знаю, имеет ли отношение к нему язык, но на всякий случай...)
Да, я бы сказал, что это связано с языком, хотя бы потому, что некоторые языки более подробные, чем другие.
В общем, я использую эти эмпирические правила:
Конечно, это действительно больше зависит от характера и сложности кода, чем от LOC, но я нашел это разумным.
В общем, количество строк не является проблемой - несколько лучше метрика - это количество общедоступных методов. Но нет правильной фигуры. Например, класс строки утилиты может иметь сотни методов, тогда как класс бизнес-уровня может иметь только пару.
Если вас интересуют измерения LOC, cyclomatic и other complex, я могу настоятельно рекомендовать Source Monitor от http://www.campwoodsw.com, который является бесплатным, работает с основными языками, такими как Java и С++, и отлично подходит для всех.
От Эрика Раймонда "Искусство программирования Unix"
В нематериальных терминах эмпирические результаты Хаттона подразумевают сладкое пятно между 200 и 400 логическими строками кода, которое минимизирует вероятную плотность дефектов, все остальные факторы (такие как умение программиста) равны. Этот размер не зависит от используемого языка - это наблюдение, которое сильно усиливает рекомендации, приведенные в других разделах этой книги, для программирования на самых мощных языках и инструментах, которые вы можете использовать. Остерегайтесь брать эти цифры слишком буквально. Методы подсчета строк кода значительно различаются в зависимости от того, что аналитик считает логической линией, и других предвзятостей (например, личится ли комментарий). Сам Хаттон предполагает, как правило, двукратное преобразование между логическими и физическими линиями, предлагая оптимальный диапазон 400-800 физических линий.
Взято из здесь
Лучше измерить что-то вроде циклическая сложность и использовать это как калибр. Вы даже можете вставить его в файл сборки script/ant/etc.
Это слишком просто, даже со стандартизованным кодом, для того, чтобы строки кода были отключены от реальной сложности класса.
Изменить: см. этот вопрос для списка инструментов циклической сложности.
Я сосредотачиваюсь на методах и (стараюсь) держать их ниже 20 строк кода. В целом класс продиктован принципом единой ответственности. Но я считаю, что это не абсолютная мера, потому что она зависит от уровня абстракции, поэтому где-то между 300 и 500 строк я начинаю искать код для новой ответственности или абстракции для извлечения.
Достаточно мало, чтобы выполнять только задание, на которое оно заряжено.
Достаточно большой, чтобы выполнять только задание, на которое оно заряжено.
Больше, не меньше.
По моему опыту любой исходный файл более 1000 строк текста, который я начну хотеть разбить. В идеале, методы должны располагаться на одном экране, если это возможно.
В последнее время я начал понимать, что удаление бесполезных комментариев может очень помочь в этом. Я комментирую гораздо более экономно сейчас, чем 20 лет назад, когда я начал программировать.
Короткий ответ: менее 250 строк.
Более короткий ответ: Mu.
Более длинный ответ: читается ли код и кратким? У класса есть отдельная ответственность? Повторяет ли код?
Для меня проблема не LOC. Я смотрю на несколько факторов. Во-первых, я проверяю свои инструкции If-Else-If. Если многие из них имеют одинаковые условия или приводят к запуску аналогичного кода, я пытаюсь его реорганизовать. Затем я смотрю на свои методы и переменные. В любом отдельном классе этот класс должен иметь одну основную функцию и только эту функцию. Если у него есть переменные и методы для другой области, подумайте о том, чтобы положить их в свой класс. В любом случае, избегайте подсчета LOC по двум причинам:
1) Это плохая метрика. Если вы подсчитаете LOC, вы рассчитываете не только длинные строки, но также строки, которые являются пробелами и используются для комментариев, как если бы они были одинаковыми. Вы можете избежать этого, но в то же время вы по-прежнему считаете небольшие строки и длинные строки одинаково.
2) Это вводит в заблуждение. Читаемость не является чисто функцией LOC. Класс может быть отлично читается, но если у вас есть счет LOC, который нарушает, вы собираетесь найти себя работать трудно выжать столько строк из него, как вы можете. Вы даже можете сделать код LESS доступным для чтения. Если вы берете LOC для назначения переменных и затем используете их в вызове метода, это более читаемо, чем вызов назначений этих переменных непосредственно в самом вызове метода. Лучше иметь 5 строк считываемого кода, чем конденсировать его в 1 строку нечитаемого кода.
Вместо этого я бы посмотрел глубину кода и длину строки. Это лучшие показатели, потому что они говорят вам две вещи. Во-первых, вложенная глубина говорит вам, нужно ли логику реорганизовать. Если вы смотрите на утверждения If или петли, вложенные более чем на 2 глубины, серьезно подумайте о рефакторинге. Рассмотрим рефакторинг, если у вас более одного уровня вложенности. Во-вторых, если линия длинная, она, как правило, очень нечитаема. Попробуйте выделить эту строку на несколько более читаемых строк. Это может сломать ваш предел LOC, если он у вас есть, но он действительно улучшает читаемость.
подсчет строк == bean подсчет.
В тот момент, когда вы начинаете использовать инструменты, чтобы узнать, сколько строк кода имеет определенный файл или функция, вы ошибаетесь, ИМХО, потому что вы перестали беспокоиться об управляемости кода и начали бюрократически создавать правила и возлагать вину.
Посмотрите на файл/функцию и подумайте о том, по-прежнему ли это удобно работать или начнет получать неудобно. Если у вас есть сомнения, позвоните в со-разработчик (или, если вы работаете с одним человеком, какой-то разработчик, не имеющий отношения к проекту), чтобы посмотреть, и поговорите об этом быстро.
Это действительно так: взгляд. Кто-то еще мгновенно получает дрифт кода, или это закрытая книга для непосвященных? Этот быстрый взгляд говорит вам больше о читаемости фрагмента кода, чем когда-либо созданных метрик линий. Это зависит от многих вещей. Язык, проблемный домен, структура кода, рабочая среда, опыт. Что ОК для одной функции в одном проекте может быть все несоразмерным для другого.
Если вы находитесь в ситуации команды/проекта и не можете с готовностью согласиться на этот подход "один быстрый взгляд", у вас есть социальная проблема, а не техническая. (Различные стандарты качества и, возможно, сбой связи.) Наличие правил по длине файла/функции не решит вашу проблему. Сидеть и говорить об этом над прохладным напитком (или кофе, в зависимости от...) - лучший выбор.
Вы правы... на это нет ответа. Вы не можете использовать "лучшую практику" как ряд строк кода.
Однако, как правило, я часто просматриваю то, что я вижу на одной странице. Как только метод не подходит на одной странице, я начинаю думать, что я делаю что-то неправильно. Что касается всего класса, если я не могу видеть все заголовки методов/свойств на одной странице, тогда, возможно, мне также нужно начать расщепление.
Опять же, на самом деле нет ответа, некоторые вещи просто должны стать большими и сложными. Тот факт, что вы знаете это плохо, и вы сейчас об этом думаете, вероятно, означает, что вы будете знать, когда остановиться, когда все выходит из-под контроля.
Линии кода гораздо больше говорят о многословии, чем о любой другой вещи. В проекте, который я сейчас работаю, мы имеем несколько файлов с более чем 1000 LOC. Но, если вы разделите комментарии, это, вероятно, останется около 300 или даже меньше. Если вы меняете объявления типа
int someInt; int someOtherInt;
в одну строку, файл будет еще короче.
Однако, если вы не многословны и у вас все еще есть большой файл, вам, вероятно, придется подумать о рефакторинге.