Как не писать быдлокод?

[alex34]

Хочется повысить свои скиллы в этой области . Так что собственно сабж. Многие конечно захотят отправить читать основы языков программирования, но мне кажется, что есть свод простых правил, особенно касающихся эмбеддерской специфики.
Так же как например на вопрос "как правильно разводить платы?" - можно буркнуть "иди, читай Хоровица", а можно дать такую статью http://cxem.net/comp/comp40.php

[BSVi]

Проблема в том, что кодинг - это немного более сложная тема, чем разводка плат. И быдлокод определяется не только оформлением, но и логикой. Правил оформления довольно много:

http://google-styleguide.googlecode.com ... pguide.xml
http://dsp-book.narod.ru/an1003.pdf

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

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

Для начала, можешь обратить внимание на базовые концепции, которые и в эмбедде вполне применимы (и даже, обязательны), к примеру, DRY.

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

[tetraa]

Спасибо за ссылку alex34, оч полезная.

[alex34]

Спасибо за ответ.
Само оформление интересует как раз меньше, я больше ориентирован на результат, поэтому оформление скорее ради уменьшения скорости дебага. И читабельности через год . А вот логические ошибки как раз интересуют больше. Например в одном проекте я написал некислый такой парсер команд и засунул его в обработчик прерывания уарта. Соответственно, во время его выполнения терялись события от прерываний с более низким приоритетом. Потом пришёл к выводу, что обработчики надо делать по возможности быстрыми, а потом уже неспеша последовательно разбираться, делать конечный автомат.
Наверняка такая ошибка где-то описана..
Кстати, на счёт шаблонов очень верно. Интересно, какие шаблоны подходят-таки к эмбеду? И какие бывают только в эмбеде?

[BSVi]

Ну, большая функция в прерывании - это просто глупость, а не высокие материи.

Ну, я пытался по распинатсья и по прикручивать шаблоны к эмбеду вот тут: https://bsvi.me/prochital-klassicheskuyu-knizhku-gofov/
Но реальность такова, что практически ничего их этого использовать не получается Шаблонов, которые используются в чисто эмбеде я не нашел.

[Qic]

Писать код надо так, чтобы:
-Открыв его он не мельтешил в глазах и четко читался и разделялся на абзацы - как текст.
-Открыв код через пол года он должен содержать минимум "а что это за хрень?" - пишите комментарии.
-Очень полезна блок схема.
-Машина состояний очень тяжелая конструкция в текстовом виде - обязательно нужна блоксхема.

ЗЫ Я не претендую на кодописателя, но в своё время много лулзов словил.

[BSVi]

Писать комменты бесполезно Комменты и код очень быстро рассинхронизируются.
Как блок-схему цеплять к коду? Каждый раз при изменении кода перерисовывать схему?

Это, конечно, классические практики, но реально они малополезны. Нужно писать код так, чтобы его работа была очевидна - это единственный вариант.

[tetraa]

+1. сам тоже коменты не пишу. стараюсь делать так чтоб код был понятен при чтении. ну может переменные називаю так чтоб можно было опредилить что это за модуль

[Qic]

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

[alex34]

Не я один мучаюсь этой проблемой...
http://electronix.ru/forum/index.php?showtopic=71733
http://electronix.ru/forum/index.php?showtopic=71401

[BSVi]

alex34, естественно, не ты один. Я в свое время тоже очень много копал по этой теме. В итоге, получилось, что нужно брать и прогать. Желательно вместе с более опытными товарищами.

[alex34]

Да я уже не первый год беру и прогаю, только получается одно и тоже всё время... и совсем не похожее на тексты гуру )

[BSVi]

А что такое - тексты гуру? Я видел много "гуру", которые программят ужасно.

[alex34]

Ну во-первых, критерий теории-таки практика. Если сделал человек сложную, но притом безглючную систему, то его можно занести в гуру . Если нет, но наприменял кучу шаблонов - из гуру его выкидываем
А если серьёзно, то разбирая чужой текст, видишь, что скажем, передаёт он параметры не по переменной, а структурой. Очевидно, гибче же это, текст более готов к изменениям, более читаем. Почему же я сам так не делал?
Это мелочь, но если таких мелочей набирается несколько десятков, его текст начинает выглядеть совсем по-другому. А главное, во многом видится, или даже чувствуется смысл... Но самому к нему приходить, похоже - путь изобретения велосипедов и долгого хождения по граблям..

[BSVi]

Я знаю пару человек, которые делают очень востребованные промышленные системы, и те не глючат, все отлично, но читать код невозможно. Они просто внимательны. И тут мы подходим к тому, что к самому программисту должны предъявляться некоторые требования. Если человек - раздолбай (типа меня), то и код будет раздолбайским, сколько бы технических приемов не применял.

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

Code: Select all

struct AddParams
{
 int a;
 int b;
 int result;
};

void Add(AddParams *params);

Много таких штук описано в книжке Фаулера "Рефакторинг"

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

[alex34]

"Если человек - раздолбай (типа меня), то и код будет раздолбайским, сколько бы технических приемов не применял."

Мне так видится, что эти технические приёмы как раз и уменьшают вероятность нараздолбайничать. И не более того. Т.е. уменьшают количество мест, где можно допустить ошибку. Рефакторинг, видимо то, что нужно, спасибо. Почитаю. Но,имхо, это не всё, есть ещё правильная логика приложения, разделение на модули, всякие эмбед-специфичные вещи, правильное использование возможностей компилятора. Хотя здесь ты, конечно, прав, это опыт на 90%.. Видимо, кроме "брать и прогать", надо ещё стремиться углублять свои познания..

[BSVi]

Вот очень неплохой обзор принципов проектирования: http://habrahabr.ru/post/169487/

[SergeyZ]

[iEugene0x7CA]

SergeyZ, старая хохма, но актуально во все времена.

[Hulihutu]

Избежать нежелательного кода непросто