Сколько строк кода должно быть в функции / процедуре / методе?[дубликат]
-
03-07-2019 - |
Вопрос
Возможный Дубликат:
Когда функция становится слишком длинной?
Недавно мне поручили незавидную задачу по проверке плохого кода, написанного другим разработчиком, и документированию плохих практик.(Конечно, это все для того, чтобы не платить за работу разработчика, а не по каким-либо альтруистическим соображениям!)
Рассмотренный код содержит несколько процедур, которые представляют собой множество строк кода - самая длинная составляет почти 600 строк.Пара проблем с этим, о которых я подумал, - это ремонтопригодность и удобочитаемость.
Хитрость в том, что мне нужно объяснить непрофессионалу, почему это плохая практика, и, если возможно, подкрепить ее хорошо зарекомендовавшим себя современным справочником.Аналогии тоже хороши.
Есть какие-нибудь идеи?
Дублировать: Когда функция становится слишком длинной?
Дублировать: Лучшее правило для максимального размера функции?
Решение
Дело не в строках кода.Как Стив Макконнелл и Боб Мартин скажем (две довольно хорошие ссылки на лучшие практики кодирования), метод должен делать одно и только одно.Сколько бы строк кода ни потребовалось для этого, единственное, сколько строк в нем должно быть.Если эту "одну вещь" можно разбить на более мелкие элементы, у каждого из них должен быть свой метод.
Хорошие подсказки ваш метод заключается не только в одном:
- Более одного уровня отступа в методе (указывает на слишком много логических ветвей, чтобы выполнять только одно действие)
- "Разрывы абзацев" - пробелы между логическими группами кода указывают на то, что метод выполняет более одной задачи.
Просто назову некоторые из них.Боб Мартин также говорит, чтобы это было около 10.Лично я обычно стараюсь снимать за 10.Если число начинает приближаться к 20, это ментальный сигнал обратить более пристальное внимание на этот метод.Но, в конечном счете, LoC - это плохой показатель практически для всего.Это всего лишь полезный индикатор, который потенциально может указать на реальную проблему.
Другие советы
Реальный ответ
Там нет конкретного номера. Р>
Конкретный ответ
Если вам нужно оправдать себя каким-то количеством юристов или что-то еще, определите максимальное количество строк, которое умещается в типичном окне редактора разработки в вашем магазине, и используйте это.
Общая практика
Вы даже не должны смотреть на это так, но в одной функции не должно быть ничего очень сложного.
Каждая единица работы должна быть делегирована своему тестируемому методу с собственным именем. Сделайте это, и все ваши методы в конечном итоге станут крошечными и удобочитаемыми без подсчета строк ......
Самый большой нарушитель, которого я вижу, это 3-4+ булевых условия, взорванных в середине выражения if. Оберните все это в одно логическое значение с хорошим именем, затем оберните все составляющие его части, которые сами по себе являются сложными.
Прежде всего, обратите внимание, что ограничение длины полностью отделено от обычной метрики, которая заключается в том, что «функция выполняет только одну функцию и делает это хорошо?» Если ответ на этот вопрос не положительный, функция, вероятно, в любом случае не очень хорошая, независимо от длины.
Специально для максимальной длины цитата из Code Complete, как правило, считается одной из лучших книг по теме практики кодирования:
Время от времени сложный алгоритм будет приводить к более длительной процедуре, и в этих условиях этой процедуре должно быть разрешено органически расти до 100-200 строк. (Строка - это некомментированная, непустая строка исходного кода.) Десятилетия доказательств говорят, что подпрограммы такой длины не более подвержены ошибкам, чем более короткие подпрограммы. Пусть такие вопросы, как глубина вложения, количество переменных и другие соображения, связанные со сложностью, определяют длину процедуры, а не налагают ограничение на длину как таковое.
Если вы хотите написать подпрограммы длиной более 200 строк, будьте осторожны. Ни в одном из исследований, в которых не сообщалось о снижении стоимости, уменьшении частоты появления ошибок или о том и другом с более крупными процедурами, различающимися для размеров, превышающих 200 строк, и вы не столкнетесь с верхним пределом понятности при прохождении 200 строк кода. / р>
Прошло много лет с тех пор, как я прочитал это, но я думаю, что в Learning Perl они рекомендовали делать процедуру не дольше, чем можно уместить все это на экране сразу. Я думал, что это был хороший критерий. Я видел более длинные функции, которые по-прежнему читались из-за повторяющегося кода (например, доступ к базе данных и назначение значений свойств), но это скорее исключение, чем норма.
Чтобы добавить точку зрения Рекса, она также должна быть как можно короче. Боб Мартин говорит, 10 или меньше
Как можно меньше.