Как долго функции/методы должны быть в среднем?

Question

Мы все читаем чрезмерно длинные методы или функции, где ваши глаза заканчиваются кровотечением, когда вы достигаете return. Мы также видели те функции с одним слоем, которые кажутся бессмысленными ...

Я просто хотел спросить: какая, по вашему мнению, лучшая средняя длина для функции/метода? Учитывая, что каждый язык имеет свои собственные способы, вы можете указать, на какой из них вы ссылаетесь в своем ответе. Спасибо!

Answer 1

Нет смысла обсуждать «среднюю длину функции». Вы должны использовать правило большого пальца. Функция/метод должна обладать очень точной функциональностью, которая должна быть представлена ​​его именем. Если вы не можете определить «что это делает» в его имени, вы должны разделить его. Но длина может варьироваться, так как некоторые очень определенные задачи требуют довольно значительного количества кода.

И, как вы сказали, глядя на некоторые функции, ваши глаза истекают кровью. Если они истекают кровью, что-то не так с функцией;)

Answer 2

Более короткие методы с множеством других вызовов метода только для уменьшения кода в одном конкретном методе не обязательно означают «лучший» метод.

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

Answer 3

Как сказал Авраам Линкольн, когда его спросили, как долго должен быть ноги человека, «достаточно долго, чтобы достичь земли».

Каждая функция/метод будет отличаться.

Answer 4

Для меня очень сложно, если функция длиннее печатной страницы. Мне также не нравится линия упаковки в распечатке. Это делает меня старомодным или я отдаю свой возраст - печатный код?

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

Таким образом, это соотношение между длиной и хорошими соглашениями об именах.

Answer 5

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

Длина метода - это бессмысленное число. Вы измеряете качество метода по его специфике, эффективности, надежности и удобочитаемости; а не сколько строк. Количество строк становится еще более бессмысленным, если вы рассматриваете разные стили кодирования - некоторые люди просто любят иметь много пробелов.

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

Answer 6

Функция никогда не должна быть длиннее экранной.

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

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

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

Answer 7

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

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

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

Answer 8

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

• Уровень абстракции: код в методе должен поддерживать однородный уровень абстракции. Я имею в виду, что это может сделать вашу голову вращением, если вам нужно прочитать метод с очень высоким уровнем вызовов, посыпанными между блоками, которые выполняют базовое смещение битов, обработку строк и т. Д. Следуя этому правилу, вы удаляете адреса для тех, кто пытается понять, что способ.
• Форматирование: код должен всегда форматироваться, чтобы оптимизировать читаемость. Когда вы добавляете блок в существующий метод, вы привязываете его к соответствующему коду. Поместите пустые строки между семантически связанными блоками. Соблюдайте правила кодирования команды.
• Комментарии: Будьте неохотно комментировать ваш код делает. Это уже написано в коде. Если вы добавите комментарии, тогда сосредоточьтесь на , почему все сделано таким образом.
• Фокус: метод должен фокусироваться на одной конкретной задаче. Вы должны иметь возможность описать реализацию в одном сводном предложении.
• Длина: Не пытайтесь сделать метод длиннее страницы монитора.

Любые другие критерии качества, которые я пропустил?

Answer 9

Мое правило: должно быть очевидно путем кратковременного осмотра (скажем, 30 секунд или меньше), что имя функции соответствует ее реализации, предполагая, что любые функции, которые он использует, имеют реализации, соответствующие их именам.

Практически это означает, что мои функции довольно короткие. Некоторые из них - простые определения.Как патологический пример:

int AdditiveInverse(int x) { return Negate(x); } 

Если AdditiveInverse и Negate разные понятия в моей голове, и просто случайно совпадают в реальном мире. Нет ничего плохого в подростковой функции, если она вводит новую концепцию.

Я нашел, что это эмпирическое правило легче снимать с довольно высокоуровневым стилем программирования. Управление памятью, отдельное прохождение индекса и т. Д. Препятствуют осуществимости этого. Я считаю функциональные языки особенно привлекательными для этого стиля: это нерушимая директива для меня, когда я пишу Haskell, и свободную эвристику, когда я пишу C#.

Answer 10

Я думаю, что ребята из Object Mentor некоторое время думали об этой проблеме. У них есть a similar question posted some years ago.

Вы можете взглянуть на этот отличный разговор, Clean Code III: Functions.

Answer 11

Предпочитают небольшие и сфокусированные функции.

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

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

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

Source

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

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

Подумайте о будущем: создайте функции, которые вы можете использовать в своих других проектах. Создание общих функций. Итак, когда вы пишете функции, старайтесь сделать их обобщенными, но не слишком много, потому что это может занять много времени, иногда, чтобы сделать их обобщенными, и у вас есть программа для завершения, не так ли? Просто держите его простым, как подсказывает руководство по стилю Google.