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

Так например:


Эта процедура занимает 250 строк (включая комментарии).
Это нормальная практика для программиста вообще и для Delphi-программиста в частности? Так и должно быть?

З.Ы.: Не было времени переводить комментарии на русский, потому извиняйте.
Также некоторые условия не оптимизированы. По-этому не швыряться тапками =) (Знаю Pascal 1 год, Delphi - 1/2 года).

Код я не читал, но 250 мне кажется очень много. Часто можно услышать фразу Дейкстры о том, что код метода должен помещаться на экране. Это очень оптимистично, конечно, но стоит к этому стремиться, мне кажется. Некоторые исследования на эту тему приведены в замечательной книжке Стива МакКоннелла "Совершенный код" (п. 7.4), которую можно достать в сети. У него всего сходится к тому, что лучше бы ограничивать длину метода 200-ми строками.

У меня обычно методы растягиваются по двум причинам 1) Метод задумывался чтобы решить одну задачу, потом универсализовывался для решения нескольких схожих
2) Когда решение сваливается в разбор разных частных случаев (иногда это необходимо для оптимизации) 
В основном получается меньше 250 строк
Многие считают что задачу надо дифференцировать до предела что бы легче решалась. Мне лично иногда хочется что бы все решение было целостное и заключалось в одном методе.
(сейчас работаю над: http://csys.webhost.ru ) 
Вот САМОЕ длинное что смог найти в написанном за последние 2 месяца 


процедура (delphi) для dll'ки кодирования данных, Этот метод растягивает/сжимает буфер побайтно, advanced мажорирование типа.



Добавлено через 6 минут и 38 секунд
Считаю что 250 конечно многовато но если надо ...
насчет "нормальная практика" открой исходники делфы и посмотри - В основном методы менее 100 строк но есть и приличненькие. А вообщето главное в методе чтобы он 1) Выполнял свою задачу и ТОЛЬКО! 2) Делала это как можно более оптимально 3) Код  был симпатичным хотябы (не буду говорить о красоте)

Добавлено через 9 минут и 43 секунды
у можно в двух словах задачу TfmDeleteRecords.sbDeleteRecordsClick ?

Добавлено через 10 минут и 47 секунд
replace:
LastMsg[1]:='А'

  Для таких вещей принято создавать несколько методов для каждой из подзадач и вызывать их из этого метода.

4d5a, 


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

Alexeis, в некоторых случаях не так все просто  как может показаться

Практика показывает, что путем некоторого напряжения мозгов метод всегда можно сократить до приемлимой величины. МакКоннел, на которого уже ссылались, предлагает свою метрику для оценки приемлимости длины метода. И это не число строк кода, а число неких точек принятия решения. Которых в идеале не должно быть больше 10 или, в крайнем случае, 20.
Длинные методы может и легко писать, но сложно поддерживать: это главный аргумент против них.
Если функция, как ей и положено, выполняет ровно одну задачу, ее несложно разбить и сократить. А если она выполняет не одну задачу - нужно переделывать дизайн.

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