Здравствуйте, _hum_, Вы писали:
__>но! для того, чтобы понять, в чем именно ошибка, придется, либо писать наиподбробнейшие тесты (вплоть до тестирования присваивания uint8_t a = b; assert(a == b); ), либо положиться на дебагер. думаю, в реальности резонно выбирать золотую середину. иными словами, "не вместо, а вместе" (с)
дебагер это как бы такая скрипучая телега со старой лошадью. да, иногда можно выгнать ее из стойла, смахнуть пыль и даже куда-то поехать, но это просто несерьезно. дебагер хорош только если вы вообще никуда не торопитесь и вам просто нравится копаться в коде. если у вас в реальной жизни дошло дело до дебагера, значит, вы делаете что-то очень и очень неправильно.

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

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