Какой размер метода/функции "в экранах" считается нормальным?
Несколько раз видел на Хабре комментарии где заявлялось что если ваши методы/функции имеют размер (в строках по вертикали) больше чем х * размер экрана (где х = 0.5..1) то вы плохой программист пишущий плохой код.
Насколько уместно это заявление? Я пишу на ASP.NET C# для «энтерпрайз» и некоторые методы занимают и по два-три экрана, потому что это всякие проверки на всякие дурацкие условия, доступ к данным, вывод и форматирование и т.п., которые и рад бы разбить на меньшие куски, но выглядеть это будет не очень — не будешь же присваивать например значения контролам 1..10 в одном методе а 11..20 в другом. Я понимаю когда уместно выделить некоторое действие в отдельную функцию, но не всегда это получается, как я писал выше.
В общем, нужно ли волноваться по этому поводу или можно забить? На сколько большие функции у вас? Особенно интересно мнение веб-разработчиков на .Net.
никакой на самом деле. лучше ответь на вопрос: для каких целей тебе важен размер на экране/кол-во строк?
у меня описание класса около 150 строк. в среднем 1 функция на 40-100 строк (как правило к каждому циклу или условиию 2-5 строк комментариев).
иногда из вложенности специально делаешь разветвленную структуру - что бы другие не тратили время на дебаг и понимание что тут твориться.
я к тому что все зависит от целей и понтов. там и размер функций подбирается под того с кем работаешь. хотя можно чисто по-русски - не думая - попросить уволить 1 программиста и нанять профессионала за 3-4 раза большую зп.
Я писал первые свои скрипты на телефоне из-за отсутствия компьютера с помощью простейшего редактора, в котором за один миг было видно только 3 строчки. Даже копирования не было приличного. Сложно было, но справился.
Так что теперь не только один хабраюзер признался;)
Ох да. Я тоже с телефона (не смартфона) поначалу писал, когда компьютера не было, правда пользовался джаббер ботом на PHP, которому через Bombus писал сообщения, а он делал для них eval() и ответечал результатом выполнения кода, таким образом кодил ему же новую функциональность…
Тогда о форматировании кода речи не могло быть вообще xD
Смысл этого правила в том, чтобы метода был обозрим с одного взгляда.
Бывает — в методе всего пять строк, но при этом 4 уровня вложенности и такие длинные выражения, что нужно полчаса потратить чтобы понять. Так что смысл не в количестве строк, а в суммарной сложности понимания метода.
Кроме количества строк есть еще длина строк, ее тоже лучше ограничивать. Я давно пишу на C# и часто делаю внутри кода отступы пустыми строками, вставляю регионы (#region). Отступы немного увеличивают количество строк, а регионы — существенно сокращают (в свернутом состоянии).
Кроме того, у меня широкоэкранный монитор повернут на 90 градусов, так что на один экран входит два обычных :)
Длинные функции/методы я в общем случае нахожу уместными разве только при каких-то нетривиальных математических расчётах. А в общем не математическом случае функции/методы длиннее 50-60 строк (пара экранов) уже начинают напрягать.
Впрочем, значительно чаще напрягает не количество строк, а их содержимое :)
Компактность!
Первое правило: функции должны быть компактными. Второе правило: функции должны быть еще компактнее. Я не могу научно обосновать свое утверждение. Не ждите от меня ссылок на исследования, доказывающие, что очень маленькие функции лучше больших. Я могу всего лишь сказать, что я почти четыре десятилетия писал функции всевозможных размеров. Мне доводилось создавать кошмарных монстров в 3000 строк. Я написал бесчисленное множество функций длиной от 100 до 300 строк. И я писал функции от 20 до 30 строк. Мой практический опыт научил меня (ценой многих проб и ошибок), что функции должны быть очень маленькими. <...> Однако строки не должны состоять из 150 символов, а функции из 100 строк. Желательно, чтобы длина функции не превышала 20 строк.
Роберт Мартин, «Чистый код» (хоть примеры и приводятся на Java, думаю что книга все равно полезная).
Если размер метода больше некоего предела — это просто сигнал о том, что что-то, возможно. не так. Но это может быть и ложная тревога.
Если сомневаетесь (вот как сейчас) — попросите коллег отревьюить.
Кстати, форматирование можно возложить на шаблонизаторы.
Если код однообразный, то можно и длинную функцию писать. Я для себя начинаю задумываться, если больше двух экранов (С). Если что, в исходнике Python есть функция и в 2000 строк :) При этом Python — весьма неплохой пример C-кода.
Я для себя взял правило — метод может иметь длину и сложность до той степени, пока я не начинаю его «чувствовать».
Пока метод не «ощущается» — он достаточно прост, если же его можно чем-то выделить из остальных — значит что-то в нём не так.
Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать. (с) Brian W. Kernighan.
однажды я испытал это на своей шкуре и вопросов с размером модулей у меня больше не возникает.
