Конкретно ручное там:
- последовательная нумерация (без контроля пропусков)
Было бы странным городить здесь какую-либо нумерацию, отличную от нумерации, основанной на множестве натуральных чисел.
А я и не предлагаю. Я говорю, что ее никто не контролирует. Значит возможен человеческий фактор, которому пофиг на ваше "множество натуральных чисел"
Или Вы предлагаете для этой цели ввести какие-либо идентификаторы? Так это легко можно сделать в секции CONST модуля, если понадобится.
Нет. Я предлагал список + итератор. В этом случае "сломать" нумерацию, проверку на конец и сброс - невозможно. Написать изначально неправильно (и тут же увидеть, что не работает) - да, можно. Но не потом, когда все работает и надо, например, добавить еще одно состояние. Решение с макросами (при том, что он мне не нравится) тоже свободно от ваших "ручных" недостатков.
- проверка на последнее значение (ручное) и сброс на начальное (ручное)
Ваше (или чьё-либо ещё) автоматизированное решение никак не избежит такой проверки, просто Вы не будете это видеть в своём автоматизированном коде.
Еще раз: эту проверку (автоматизированную)
невозможно сломать, если она изначально правильно написана. Ваша "ручная" проверка - может быть сломано каждый раз, когда добавляется/удаляется состояние.
Кто-то будет не в курсе, что вы где-то особенным образом шаманите с этой s и будет получать "неожиданные" результаты.
Документирование модуля никто не отменял. Уж, хотя бы на уровне комментариев. На всякий случай напомню: комментарии должны дополнять исходный текст, а не дублировать его.
На всякий случай напомню: документирование - последняя и самая неэффективная мера по поддержанию кода в рабочем состоянии. После компилятора и тестов.
... я бы однозначно избавился от глобальной (или static) переменной в пользу аргумента, имеющего смысл "текущее состояние".
А я бы решительно запретил это делать.
В таком случае вы просто не сможете использовать более одного "автомата". Очень странное ограничение для общего решения.
Надо сказать, что использование глобальных переменных в среде крутых программистов считается чуть-ли не позорным занятием.
Да. И этому есть вполне разумные объяснения. Которые, правда, не всегда доходят, пока не прочувствуешь сам
В моём же понимании настоящий программист всегда знает где лучше использовать локальную переменную, а где глобальную.
Конечно. Я же оговорился - все сильно зависит от конкретных обстоятельств.
Кроме того, если ограничить свой выбор каким-либо Оберон-языком, то для решения поставленной тривиальной задачи невозможно избавиться от глобальной переменной.
Вы вообще читаете то, что я пишу?
Передавайте в качестве аргумента - и все будет возможно
Дело в том, что в этих языках процедура не в состоянии хранить какой-либо контекст после своего завершения: её кадр будет снят со стека вместе со всеми локальными переменными. После неё может остаться только РЕЗУЛЬТАТ её работы. И этот результат она может сохранить для объемлющих блоков только в глобальных по отношению к ней переменных. Всё это называется блочной структурой. Описанные свойства я расцениваю как положительные. Если какой-либо язык нарушает эти принципы, то мне такой язык даром не нужен.
Гхм. Если все эти глубокие размышления про блочную структуру всего лишь наезд на сишные static-переменные уровня функций - то мимо
Они ничем не отличаются от обероновских глобальных переменных, только область видимости у них ограничена функцией. Что, безусловно, однозначный плюс. Особенно, когда вы хотите быть уверенным, что никто не начнет шаманить с "s" за пределами функции