Длинные блоки - это само по себе не плохо. Это нормально и где-то неизбежно, если не принимать откровенно искусственных решений. Плохо, когда у длинных блоков начинается разнообразная и непредсказуемая вложенность. И тогда уже никакие отметки на end-ах делу не помогут.

Когда в конце процедуры образуется лесенка из 4-5 end - это верный признак кривого нуждающегося в улучшении кода сверху от них. Я сейчас пробежал глазами страшный легаси модуль, на переделку которого точу зубы с тех пор как пришёл в этот проект - и то больше трёх end-ов подряд нигде не увидел.

Ну в общем, да. Один end на процедуру, один на finally - то есть нормально два. Один резервный - на какую-нибудь доп. хрень. А вот когда их 4-5 - это уже наворочено.


Ну для начала, очевидно



а дальше уже надо предметно смотреть, что внутри этих case-ов. В недавнем прошлом, когда я занимался такой хренью, лучшим оказался подход



но это уже принципиально зависит от.

Я не возьмусь сформулировать математически строго - сама область слишком зыбкая и растяжимая. Попробую примерно так:

1. Линейный блок (то есть тот, где передача управления идёт строго сверху вниз) может быть столь длинным, сколь нужно для конкретной задачи. Это нормально читается и не создаёт практических проблем. В том числе он может включать в себя локальные (то есть небольшие) ветвления и циклы, это не мешает. В том числе он может быть завёрнут в try.

2. Цикл может включать в себя длинный блок (а-ля блок из первого пункта) если он такой один и занимает практически всё тело подпрограммы (практически всё - в смысле, что до цикла и после цикла может быть несколько технических строк, но ничего существенного).

3. В ветвлении совершенно недопустимы два длинных блока (if условие then длинный else длинный). Ветвление с одной веткой (if условие then длинный) чаще всего следует переписать как (if not условие then exit; длинный). Ветвление с одной длинной и одной короткой веткой нежелательно. Если таки не удаётся его избежать, короткая ветка должна идти первой (if условие then длинный else короткий) следует переписать как (if not условие then короткий else длинный).

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

Всё правильно. Там, где нет возможности для одного глобального улучшения, надо идти шаг за шагом.


В твоём случае - возможно. В моём - это неизмеримо лучше. Краткая характеристика моего случая в терминологии из твоего примера: FSelRow - несколько десятков, условно группируемых на два подтипа, склонны к регулярному пополнению; клавиши - пара десятков, стабильны, обработчики - в большинстве случаев типовые, частично - типовые для подтипа FSelRow, время от времени - особые, однажды прописанные, почти никогда не меняются. Соответственно, какое удовольствие было ползать среди двух десятков простыней, содержащих case на полсотни вариантов каждая.... я как один раз его ощутил, так сразу и переделал на короткий элегантный модуль, в котором добавление нового FSelRow делается за несколько минут, просто-напросто добавлением нового класса и доопределением в нём трёх-четырёх методов.

Я допускаю, что Макконнел заглядывал в мой код, когда писал свою книгу.


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

Верное решение.


Боюсь тебя огорчить, но я померял. Между версиями v1 и v2 (последними перед переделкой) добавление 4-х FSelRow по старому типу привело к увеличению кода на 95 строк. Между версиями v3 и v4 (первыми после переделки) добавление 2-х FSelRow по новому типу привело к увеличению кода на 52 строки. Если вычесть из этих строк пустые и комментарии, думаю, окажется, что код ещё и сокращается. Впрочем, это в любом случае неважно. Размер кода важен, когда маневрируешь между простынями. Здесь же FSelRow собран в компактный лежащий вместе класс, размером, например (у последнего из добавленных) 36 строк, с которыми ты и работаешь. До всего остального кода просто нет никакого дела. Если захочется, можно, например, вынести этот FSelRow в отдельный файл и наслаждаться "разросшимся кодом" менее 50 строк.

В смысле, программный код, содержащий такую конструкцию.


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