Микроконтроллеры

Да наверняка все очевидные ситуации там рассмотрены. Бояться надо ситуаций на которых глаз замылился. Вот для этого и нужно чтобы код посмотрели независимые люди по хорошему. И пусть 99,99% претензий будут вкусовыми. Но даже один найденый косяк буде уже хорошо. А бумажное оформление такой процедуры причесывает мысли. Мне в свое время помогла книга ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, ЧТОБЫ… ВЫСТРЕЛИТЬ СЕБЕ В НОГУ. За 10 лет только убедился что многие мысли правильные. На тему - не можешь документировать - не сможешь написать хороший код. Если вы не можете сказать это по-английски, то вы не сможете выполнить это и на Си/Си++ Это правило с последующим также относятся к правилам пользовательского интерфейса, но здесь под "пользователем" уже понимается программист, использующий написанный вами код — часто это вы сами. Акт записи на английском языке описания того, что делает программа, и что делает каждая функция в программе, является критическим шагом в мыслительном процессе. Хорошо построенное, грамматически правильное предложение — признак ясного мышления. Если вы не можете это записать, то велика вероятность того, что вы не полностью продумали проблему или решение. Плохая грамматика и построение предложения являются также показателем небрежного мышления. Поэтому первый шаг в написании любой программы — записать то, что делает программа, и как она это делает. Есть разные мнения о возможности мышления вне языка, но я убежден, что аналитическое мышление того типа, который нужен в компьютерном программировании, тесно связано с языковыми навыками. Я не думаю, что является случайностью то, что многие из знакомых мне лучших программистов имеют дипломы по истории, филологии и схожим наукам. Также не является случайностью то, что некоторые из виденных мной худших программ были написаны инженерами, физиками и математиками, затратившими в университете массу энергии на то, чтобы держаться как можно дальше от занятий по языку и литературе. Сущность заключается в том, что математическая подготовка почти не нужна в компьютерном программировании. Тот тип организационного мастерства и аналитических способностей, который нужен для программирования, связан полностью с гуманитарными науками. Логика, например, преподавалась на философском факультете, когда я был в университете. Процесс, используемый при проектировании и написании компьютерных программ, почти полностью идентичен тому, который используется, чтобы сочинять и писать книги. Процесс программирования совсем не связан с теми процессами, которые используются для решения математических уравнений. Здесь я делаю различие между информатикой (computer science) — математическим анализом компьютерных программ — и программированием или разработкой программного обеспечения — дисциплиной, интересующейся написанием компьютерных программ. Программирование требует организационных способностей и языковой подготовки, а не абстрактного мышления, необходимого для занятий математическим анализом. (В университете меня заставили проходить год на лекции по математическому анализу, но я никогда из него ничего не использовал ни на занятиях по информатике, хотя для них матанализ был необходимым условием, ни в реальной жизни). Я как-то получил открытую рецензию на книгу, посвященную мной предмету проектирования компиляторов, в которой рецензент (который преподавал в одном из ведущих университетов) заявил, что он "считает абсолютно неуместным включение исходного кода компилятора в книгу о проектировании компиляторов". По его мнению, необходимо учить "фундаментальным принципам" — лежащей в основе математике и теории языка, а детали реализации — "тривиальны". Первое замечание имеет смысл, если у вас создалось впечатление, что книга написана ученым- специалистом по информатике, а не программистом. Рецензент интересовался лишь анализом компилятора, а не тем как его написать. Второе замечание просто показывает вам, насколько изолировала себя научная элита от реального труда программирования. Интересно, что основополагающая работа по теории языка, сделавшая возможным написание компиляторов, была выполнена в Массачусетском технологическом институте лингвистом Наумом Хомским, а не математиком. Обратной стороной этой медали является то, что если вы зашли в тупик при решении проблемы, один из лучших способов выйти из него — это объяснить проблему приятелю. Почти всегда решение возникает в вашей голове посредине объяснения