Насколько велика должна быть длина функции (строки кода в функции)? [дублировать

Question

Возможный дубликат:
Сколько строк кода должно иметь функцию/процедуру/метод?

Я хотел бы знать, сколько строк кода должно быть функцией? Сколько строк слишком много.

Я прочитал это некоторое время назад, это около 10 или 20 линий, но это было потому, что экран будет размещать только так много линий. Теперь, когда размер экрана становится больше, это не будет верно.

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

Я хотел бы услышать, что другие говорят об этом.

Спасибо.

Примечание: Дублировать Когда функция слишком долго?, не мог найти его, когда я опубликовал.

Answer 1

Этот вид вопроса хорошо отвечает в Код завершен. Анкет Стив МакКоннел написал целая страница Чтобы ответить на этот вопрос. Его заключение:

Десятилетия доказательств говорят, что процедуры такой длины (> 100 строк) не более подвержены ошибкам, чем более короткие процедуры. Пусть такие проблемы, как сплоченность рутины, количество точек принятия решений, количество комментариев, необходимые для объяснения рутины, и другие соображения, связанные с сложностью, определяют длину рутины, а не навязывая ограничение длины как таковое. Тем не менее, если вы хотите писать процедуры дольше, чем около 200 строк, будьте осторожны.

Answer 2

Линии не имеют значения, но сложность.

Функция должна выполнять одну задачу, и она должна быть очевидна. Вам не нужно больше, чем несколько минут, чтобы точно понять, как и какая функция.

Answer 3

Это должно быть столько, сколько нужно.

Я не вижу никакой точки зрения в ограничении функциональной линии для размера экрана (ОК, чтобы быть справедливым, я не начал программирование, пока после экрана не смогут соответствовать более 10-20 линиям-возможно, это имело смысл в некоторых средах) Анкет Просто напишите функцию, как это имеет смысл. Когда он становится настолько большим, что кусочки кода начинают повторяться, рефакторируйте эти части другим функциям/классам/компонентам.

Answer 4

Это довольно произвольное правило. Некоторым вроде 20 строк, другим нравится правило без прокрутки. В конце концов, просто убедитесь, что он читается и легко понято с первого взгляда. Прочитайте свой Солидные принципы и убедитесь, что метод имеет только 1 ответственность и т. Д.

Answer 5

По мере необходимости, как можно меньше.

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

Если вы этого не сделаете немедленно Поймите, что делает часть кода, напишите для нее новую функцию.

Answer 6

Я не думаю, что важно, сколько линий у него есть ... пока это эффективно.

Любой код, который может быть использован в любом месте вашей кодовой базы, должен быть перемещен в другую функцию/метод в том же классе или общий класс и вызван.

Answer 7

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

Answer 8

В документе в стиле кодирования ядра Linux говорится:

Функции должны быть короткими и сладкими, и делать только одну вещь. Они должны соответствовать одному или двум экранам текста (размер экрана ISO/ANSI составляет 80x24, как мы все знаем), и делать одну вещь и делать это хорошо.

Теперь я понимаю, что это в контексте кода ядра, но я думаю, что некоторые из моментов, которые он делает Re: Длина функции, в целом действительна. Найдите копию здесь. Анкет Раздел о функциях - глава 4.

В целом, длина функции не должна быть ограничена некоторым искусственным правилом; Фактор, если это имеет смысл, и потому что это облегчает чтение, но правило около 1-2 экранов не написано на камне.

Answer 9

Это всего лишь мнение из OO-persiption:

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

Очень тривиальный функциональный пример будет вместо того, чтобы иметь функцию, которая вычисляет встроенную последовательность Fibonacci в цикле, я бы добавил функцию преемника (int a, int b), которая вызывается функцией fibonacci ().

Более сложным примером в моде будет клиент HTTP, который выполняет запрос на получение GET. Я бы разбил это на что -то вроде этого:

Connection getConnection(String host, int port)
Request createRequest(String[] params)
void sendRequest(Request r)
String getResponse(Connection c,Request r)

Answer 10

Функции должны быть достаточно малы, чтобы выполнять свою работу, но не меньше.