Профориентации псто

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

Вот только поддерживать мне его больше не придется... Это мой последний проект - тот самый, с которого меня "попросили оттель" еще в июне. А жаль - я его два года ваял.

Вы опять мыслите категориями компьютерной игры. Ладно, допустим, действие "закрыли" и впрямь "битовое"; но даже действие "открыли" уже параметрическое (открывается на ту или иную величину). Плюс всё это происходит в реальном времени. Плюс если вы думаете, что движение в этом времени распределено равномерно, то вы тоже зря так думаете: чуть раньше времени начал открывать - задел поверхность; а значит, надо продумывать раствор зажима и расстояния до основания. А когда в зажиме что-то есть - еще и делать при движении поправку на размер и форму этого "что-то". Поэтому в функции и есть куча внутренних переменных состояния, и поэтому нельзя просто побить функцию на две, а потом сначала запустить одну, а потом другую. Это, я повторюсь, один большой процесс, в котором детали малых процессов неразрывно переплетены между собой. Однако ж, если в данный конкретный момент некоторые малые процессы не нужны - они не запускаются, и соответствующие им параметры никто не передает. Да, для многих это переплетение будет непонятной магической лапшой - ну так, возможно, им просто не стОит лезть работать в такую область?

Может быть, можеть быть... Видимо, попросту до сих пор это никогда не было нужно: не того масштаба задачи. Я полагаю, надо решать проблемы по мере возникновения: если потребуется - освою и это. Хотя, с учетом написанного в этом топике, и вообще не факт, что я еще в принципе вернусь в АСУ.

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

Оооохохохохо, вы не поверите! Бывало такое, что я приходил как раз на проект, где раньше работал такой вот современный выпускник, всё писавший объектно и по правилам хорошего тона. Код был красив и безупречен, а работа шла медленно и даже визуально неоптимально: действия не выполняются параллельно, инерция от предыдущего движения не используется по назначению (движение полностью останавливается, потом продолжается дальше в скорректированном направлении - плавности нет). Прихожу я, разрываю красивые самостоятельные функции, расцикливаю небольшие циклы вручную, похериваю объектность, местами даже завожу стилистически ужасные глобальные переменные для обмена данными между независимыми функциями - и вуаля, выхлоп продукции увеличивается в полтора раза. Код выглядит как белый пушной зверь, склонный к полноте, но заказчик доволен, считает барыши и делится ими со мной. Простите, но нельзя ухватить все плюшки разом - чем-то надо жертвовать, чтобы получить что-то другое. Мой подход - жертвовать изящностью кода и высоким стилем, чтобы получить высокую производительность.

И - да, я понимаю, что если б такие проекты подразумевали рост и расширение, то такой мой стиль был бы провальным: с какого-то момента код превратился бы подобие бабушкиного свитера, распущенного котом - ни носить, ни восстановить. Но в том-то всё и дело, что я работаю с конечными автоматами, которым попросту некуда "расти": я использую их возможности по максимуму, и отлично знаю, что расширять дальше их будет попросту некуда. А будут новые устройства - будет новый код, вот и всё. Хотя, ясен перец, самые удачные куски старого кода я сопру и вставлю в новый, даже если договором это будет запрещено

Ну, если это будет технически возможно, конечно (в смысле совместимости).

Я знаю. Собственно, я не писал на пыхе уже два десятка лет - он мне дал кик-старт, как паскаль в качестве образовательного языка дает кик-старт пацанам, которые потом начнут ваять на сях и других адекватных языках; но после пыху на смену пришел луа, и вот там уже стало удобно и вольготно.

Зря подозреваете. Вызывающая функция вообще не заморачивается: читает xml и напрямую пихает полученные данные в параметры функций, выполняющих действия - те сами должны разобраться, что им передали. И - нет, проверка входных параметров занимает в самом крайнем случае 10% тела функции (в случае мелких операций; а чаще 2-5%). Да и вся проверка-то выглядит как if type(x) == "number" ...