Когда я должен нарушать функцию?

Question

Его разумно разбить длинную функцию на главную функцию и вспомогательные функции.

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

Учебники ограничивают количество строк, но я чувствую, что это слишком жестко.

P.S. Я программирую на Python и нуждаюсь в обработке входящих сообщений. Функция возвращает кортеж, содержащий сообщение, но во внутренних типах данных Python. Таким образом, для каждого типа сообщений вы можете видеть несколько независимых кодов.

Дубликат Вопрос

When is a function too long?

Answer 1

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

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

Я не думаю, что в строках кода тоже должно быть жесткое число, но хорошо написанный код не имеет методов с более чем 5-10 строками в нижних слоях и от 20 до 30 строк в бизнес-логике. Чтобы дать вам какую-то метрику.

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

лично я разрушаю функцию, если она либо сохраняет общие строки, либо общее время обработки.

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

Answer 7

Дело в том, что в принципе лучше иметь специальные функции. Но где установить предел, очень сильно зависит от 1) «обычный» стиль программирования на некоторых языках. (можно заметить, что объектно-ориентированные langauges имеют тенденцию к более коротким процедурам, чем, скажем, C или тому подобное 2) это зависит от вашего способа программирования. Каждый жесткий предел должен быть поставлен под сомнение. ИМХО. В целом, вероятно, будет некоторое «естественное» распределение программ 3) Я думаю, что нужно помнить о том, что функция должна выполнять определенную задачу, например, некоторая функция для синтаксического анализа обычно намного дольше, чем функция, просто устанавливающая некоторые поле в структуре. Или вернемся к рассмотрению того, как может выглядеть цикл событий в Windows API. Так что все указывает на то, что могут быть веские причины для длинных методов ...

Answer 8

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

Answer 9

Размер не имеет значения. Судите меня по моему размеру? - Yoda

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

Answer 10

Если вы этого не пишете и уже в производстве: НИКОГДА !!! Если вы сломаете его, вы, вероятно, сломаете его, это так просто.

Если вы пишете его, и вы не уверены, на экране будут использоваться яблоки, как и другие.

Answer 11

Существует множество причин разбить длинную функцию на ее составные части. Наиболее важным является:

• читаемость
• ремонтопригодность
• код ясности/Намерение

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

Answer 12

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

Answer 13

Ну, так как я кодирую на Python, я имею право писать функции внутри функций, в отличие от C, C++ или Java. Это я считаю лучшим выбором.

Answer 14

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

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