В процессе разработки программного обеспечения зачастую возникают трудности и препятствия, которые требуют придельного внимания и определенных навыков для того, чтобы успешно завершить проект. Последнее, что хочет инженер, это проблемы, связанные с языком программирования. В большинстве случаев во встраиваемых системах используется язык C, и, несмотря на преимущества сред разработки и структурного программирования, время от времени инженеры допускают ошибки, приводящие в конечном итоге к багам и кошмарам при обслуживании продукта. Поэтому ниже приводятся советы, позволяющие избежать их появления.
Совет 1 — не используйте goto
Примерно пару десятилетий назад, когда компьютерное программирование, каким мы его знаем сегодня, пребывало в состоянии младенчества, последовательность выполнения программ в первую очередь определялась командой goto. Она позволяет перепрыгнуть с одной части кода к другой. Вот как это выглядит:
В конечном итоге в языки программирования начали встраивать такой элемент как функция, который позволяет «разорвать» линейное выполнение кода, но в отличие от goto после завершения работы функции будет выполнен переход на следующую строчку кода, где был совершен разрыв, то есть после вызова функции. На примере листинга 2 мы видим, как улучшается структурируемость программы и ее читабельность, а программы с goto сложно понимать и поддерживать.
Совет 2 — используйте for(;;) или while(1)
Если goto нынче не в моде, то инженеры могут задуматься, каким же тогда образом организовать бесконечный цикл? Решение заключается в использовании преимуществ выражений for и while, имеющихся в языке C. В листингах 3 и 4 показаны примеры их применения для организации бесконечного цикла.
В данном случае выражение, где должно прописываться условие выполнения цикла, не содержит условия как такового, поэтому цикл будет повторяться всегда.
Совет 3 — используйте соответствующий для текущей задачи условный оператор
Время выполнения программы может в значительной степени зависеть от типа условной структуры, которая необходима для принятия одного из решений. Многие разработчики аппаратного обеспечения знакомы с простым оператором if, однако некоторые могут не знать, что если не выполняется первое выражение после if, то можно задействовать оператор else для дальнейшей возможности принятия решений. Это поможет разгрузить процессор от лишних операций, связанных на обработку новых if. В листинге 5 в коде «до» если переменная Var равна 1, то программа все равно пойдет дальше проверять равенство Var нулю. В коде «после», где используется else, оценивается только первое выражение. Это экономит процессорное время и делает код более понятным.
Но и структуры типа if/else if/else тоже могут быть не всегда уместными. Если нужно проверить целый ряд условий, то более подходящим будет оператор switch. Он позволяет процессору оценить выражение и затем выбрать из списка вариантов одно решение, соответствующее истинности этого выражения. Листинг 6 делает то же, что и листинг 5, только через оператор switch.
Совет 4 — избегайте ассемблерных вставок
Для процессора естественным языком является ассемблер. Написание программы на языке низкого уровня может повысить эффективность кода, однако, люди не привыкли думать на таком языке, и, как показывает практика, иногда написание кода на ассемблере приводит к некоторым недоразумениям. Эти недоразумения в итоге приводят к появлениям ошибок и трудностям понимания и поддержки программы. Поэтому рекомендуется не прибегать к ассемблерным вставкам без явной необходимости. Дело в том, что современные компиляторы научились компилировать очень эффективный код. Разработка программы на языке высокого уровня, например, C/C++, позволяет получить более организованную структуру, которую легко понять и поддерживать. В листинге 7 сравнивается операция инкремента 32-разрядной переменной на ассемблере и на C.
Необходимость применения ассемблера все же возникает, но таких случаев немного. К одним из них можно отнести разработку загрузчика или бутлоадера. Здесь во время старта необходимо быстро решить что запускать — приложение или бутлоадер. В этом случае оптимизированный ассемблерный код может быть кстати. Другим примером может служить разработка контура управления с жесткими временными рамками при цифровой обработке сигналов. Для того, чтобы максимально сжать каждый такт, имеет смысл использовать ассемблерные вставки. Только желательно хорошо комментировать ассемблерный код, это поможет в будущем быстро разобраться с написанным.
Совет 5 — используйте преимущества принципа модульности
Некоторые разработчики аппаратных средств совершенно не умеют структурировать код. Не редкостью бывают программы с главным модулем main, состоящим из 25000 строк. В таких приложениях все переменные являются глобальными, функции используются крайне редко, а ходом программы управляют команды goto. 15 лет назад быть может это и было нормой, но не сейчас! Язык C дает инженерам возможность разбить код на отдельные функции. Это облегчает навигацию по коду, а также способствует пониманию инженером принципов, принятых в объектно-ориентированных языках, например, принципа инкапсуляции. Везде, где это имеет смысл, стоит организовывать код в логические модули. Это займет немного времени, зато потом поможет сэкономить время при отладке.
Совет 6 — пишите код в виде лазаньи, а не в виде спагетти
При сравнении пасты с программой на ум приходит два вида блюда — лазанья и спагетти. Спагетти представляет собой перемешанную лапшу, где лапшинки хаотично переплетаются друг с другом, то есть она являет собой полное отсутствие какой-либо структуры. Написание неструктурированного кода подобно готовке спагетти, в итоге получается непонятно что.
В лазанье же лапшинки лежат друг на друге слоями, что придает еде некую структуру. Код, разбитый на слои, не только прост для понимания, но и дает возможность с легкостью убрать слой и заменить его на новый. Это повышает шансы на его повторное использование в каком-нибудь другом приложении. На рисунке 1 показана структура кода в виде лазаньи.
Совет 7 — используйте описательные имена переменных
Одним из препятствий при написании большой программы, которая должна быть проста для понимания, являются неясные имена переменных. В попытках сделать имена переменных как можно короче, разработчики зачастую придумывают сокращенные зашифрованные названия, которые смогут понять только они, и то лишь далеко не всегда. Современные языки поддерживают имена переменных длиной до 100 символов. В общем, нужно называть вещи своими именами, это облегчит понимание кода не только для написавшего его программиста, но и для тех, кто в дальнейшем будет работать с этим кодом.
Совет 8 — не используйте слишком часто выражения #pragma
В языке C существует специальный тип оператора известный как #pragma. Эта препроцессорная директива зачастую работает с нестандартными синтаксическими выражениями и функциями. Использование таких директив следует по возможности избегать, поскольку они нестандартны и могут быть не портируемым с одного процессора на другой. Некоторые компиляторы могут требовать их для задач вроде определения обработчика прерываний. В таких случаях без #pragma не обойтись. Но по возможности храните #pragma вместе в одном или двух модулях. Это облегчает при портировании кода поиск мест, где необходимо внести изменения.
Совет 9 — ошибки не всегда таковы, какими кажутся
В зависимости от сложности компилятора при обнаружении ошибки сам корень ошибки может быть вовсе не там, куда указал компилятор. Причина заключается в пошаговой компиляции программы. Часто в качестве виновников возникновения ошибок являются следующие случаи:
- Отсутствие нужных файлов для их включения с помощью #include. В этом случае все объявления, находящиеся в неуказанном заголовочном файле, будут в основной программе указываться как ошибки.
- Отсутствие точки с запятой (;). Это одна из наиболее частых ошибок.
- Отсутствие закрывающей скобки ( } ). Еще одна распространенная ошибка.
- Отсутствие запятой (,). В сложных выражениях ее так легко пропустить.
Когда компилятор указывает на конкретную строчку, но в ней нет ничего подозрительного, то стоит посмотреть на строчку выше, возможно, там пропущена точка с запятой или еще что-то. С опытом искать подобные ошибки будет становиться все легче.
Совет 10 — хороший программист не обязательно должен писать как можно меньше строк
Это распространенное заблуждение, что хороший программист может написать меньше строк кода, чем среднестатистический программист. Это не так! В первую очередь хороший программист должен иметь хорошо продуманный и структурированный код. Переменные должны иметь красивые и понятные имена и быть инкапсулированными, в программе должно быть лишь небольшое число глобальных переменных. Функции должны быть краткими и четкими. Если код выглядит запутанным, и если написание дополнительных строк внесет ясность, то сделайте это! Хороший программист пишет чистый код, который легко понять и поддерживать.
Перевод © digitrode.ru