Меньше, чем сейчас.

Вступление

В прошлой жизни, прежде чем стать разработчиком программного обеспечения, я был пехотинцем в армии США. Я обычно проходил 12 миль за один раз с примерно 45 фунтами снаряжения. Однажды мы прошли 20 миль. Я не спал 3 дня подряд, патрулируя.

Это были долгие-долгие мили и долгие-долгие дни.

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

Было 12 аргументов, включая kwargs, десятки переменных локальной области видимости, которыми манипулируют по-разному, и ужасающие комментарии вроде «Надеюсь, это не вернется и не укусит меня…»

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

Я здесь отчасти шучу. Только частично.

Долгие функции свидетельствуют о потере контроля

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

Мы кузнецы логики, работающей на кремнии, и для создания сложных систем мы должны сохранять жесткий контроль над нашими инструментами и материалами.

Первоначальный разработчик этой гигантской функции явно потерял контроль.

Они отказались от поводья и позволили лошади вести себя сам.

Вместо того, чтобы сгибать материалы по своему вкусу, они сгибали проявитель.

Последствия долгих функций

Чем крупнее функция и сфера ответственности, тем сложнее ее отлаживать, обновлять и рефакторинг.

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

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

Рекомендации по длине функции

Сделайте их маленькими. Сделайте их простыми.

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

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

Может ли функция быть слишком маленькой?

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

См. Функцию ниже:

Приведенный выше код не может быть собственной функцией. Он усложняет то, что на самом деле очень просто. Звонить items_list.append(item) намного лучше.

Практическое правило

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

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

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

Длина функции и выбор языка

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

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

Контрольный список из 3 частей для написания функций

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

Каждая функция должна иметь:

  1. Одна ответственность - Принцип единой ответственности гласит, что функция или класс должны иметь одну ответственность. Если функция имеет составные if операторы и многочисленные переменные разных типов, то она, вероятно, обременена более чем одной обязанностью. Разделите это на части.
  2. Один уровень абстракции. Функции более высокого уровня и общедоступные функции не должны также выполнять действия более низкого уровня, такие как непосредственное управление структурами данных. Отделите публичное поведение высокого уровня от внутренних реализаций более низкого уровня.
  3. Минимальное количество аргументов. Функция с множеством аргументов сигнализирует о росте сложности и, вероятно, нарушает одно из приведенных выше правил. Чем больше аргументов, тем труднее использовать и поддерживать функции. Постарайтесь, чтобы ваши аргументы не превышали 2. Если функция имеет 3 или более аргумента, ищите возможности разделить ее части.

Удачного кодирования!

Больше контента на plainenglish.io