Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/recomendations from google doc #84

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

nikitoz236
Copy link
Contributor

No description provided.

@@ -294,6 +294,31 @@ if (cond1) {

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

Плохой пример:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Файлик называется embedded_c.en.md, а контент на русском.


Например вместо:
```C
void input_handler(unsigned input) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Мне кажется, пример неудачный. Надо что-то посложнее. Тут я вижу из плюсов только то, что код быстрее на микросекунду будет работать, а из минусов: надо проверять индекс на выход на пределы массива; если искать функции просто поиском, они нигде не вызываются, а только лежат в каком-то массиве, который ещё надо понять как работает; ну и скорее всего придется делать обертки, т.к. вряд ли окажется, что все обработчики одного типа.

В общем, имхо в самом switch-case нет ничего плохого. И он много где используется у нас. Надо подобрать более подходящий пример, где его лучше не использовать


Лушче написать так:
```C
#define INPUTS_NUMBER 2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

В принципе можно и без этого обойтись, а использовать ARRAY_SIZE


# Переиспользование
Нужно использовать код повторно. Не нужно писать код если он уже написан. Если чтото существующее подходит не нужно делать чтото новое.
Чтобы не оставлять ошибки в дубликатах, экономить силы программиста и прочее. Читать подробнее в [Википедии](https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B2%D1%82%D0%BE%D1%80%D0%BD%D0%BE%D0%B5_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BA%D0%BE%D0%B4%D0%B0).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Может юникодную ссылку вставить?



# Поллинг
Не должно быть периодически вызываемых функций с проверкой флагов. Поллинг это плохо. Тратится процессорное время и память для флагов которые проверяются. Также не понятно кто этот флаг ставит, кто его проверяет.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ну тоже не согласен. Вот в WBIO поллинг. Написано категорично, переделываем? А отказаться от поллинга не всегда возможно.
Тратится процессорное время и память - тоже так себе аргумент, зачем они нужны, если их не тратить?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

архитектура без поллинга всегда лучше. то что мы используем поллинг это наши привычки и лень.

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

У любого кода есть причина выполнения, вот в обработке причины и нужно вызывать выполнение кода, или запланировать его выполнение.
Используйте инструменты организации кода - корутины и таймменеджер. В прерываниях планируйте задачу с обработкой в бэкграунде. Не используйте флаги.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ну сам таймменеджер внутри флаги поллит же


# Не пишите лишний код, не выполняйте не нужные действия в коде
Пример: если файл с настройками не найден, прошивка использует дефолтные настройки. Не нужно сохранять файл с дефолтными настройками. Файл нужно записывать только если пользователь чтото поменял.
Чтение файла с дефолтными настройками ничем не отличается от отсутствия файла. По этому можно избавиться от лишней операции записи, расхода места иизноса флеш памяти, кода который эту запись делает.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Чтение файла с дефолтными настройками ничем не отличается от отсутствия файла. По этому можно избавиться от лишней операции записи, расхода места иизноса флеш памяти, кода который эту запись делает.
Чтение файла с дефолтными настройками ничем не отличается от отсутствия файла. Поэтому, можно избавиться от лишней операции записи, расхода места и износа флеш памяти, кода который эту запись делает.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants