Есть ли оптимальное количество строк кода на функцию? [закрыто]

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

Это заставляет меня задуматься: существует ли оптимальное количество LOC на функцию? Если так, что это, и это отклоняется между языками?

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

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

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

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

Здесь ничего нет.

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

Будьте лаконичны. Если ваша функция делает несколько вещей, вероятно, будет хорошей идеей разбить ее на более мелкие.

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

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

Таким образом, в Smalltalk среда «побуждает» вас писать короткие методы длиной не более 6 строк. (Обычно этого достаточно; Smalltalk - довольно лаконичный язык.)

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

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

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

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

Ответ, конечно, 42 .

Важно отметить: ни одна функция не может нарушать SRP , или вам придется столкнуться с инквизицией спаниша .

Несколько советов, как уменьшить количество строк:

• Есть комментарии, отмечающие отдельные разделы? Эти разделы должны быть функциями.
• Существуют ли цепочки if-else или операторы switch за пределами фабрики / производителя? Вашему дизайну могут потребоваться более совершенные шаблоны проектирования, чтобы помочь вам разделить обязанности.
• Легко ли проверить ваши функции? Сделайте свои функции легко тестируемыми, они развалится.
• Это сложно и просто без земли (1000 линейных монстров)? Сделайте рефакторинг лома - это рефакторинг и не сохраняйте его в надежде получить информацию об обязанностях кодов.

Вот несколько подсказок:

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

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

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

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

• Если вам нужно делать заметки во время чтения функции, это слишком долго.

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