как писать на С в 2016 году Опции

[Jenya7]

прочитал интересную статью. решил поделиться.
https://habrahabr.ru/company/inoventica/blog/275685/

[sigmaN]

То что некоторые называют "говнокодом". Хотя, надо бы банить за применение такого определения.

Т.е. книгу М.Фаулера Рефакторинг вы тоже не рекомендуете? А ведь там как раз вполне серьезно вводится понятне code smells и даже проводится аналогия с детскими пеленками кажется ))))

Нет уж. Говнокод это как раз таки абсолютно обоснованное понятие. И это не то-же самое, что разные стили оформления кода(на что будет влиять упомянутый Visual Studio с Visual Assist). В процессах построения ПО уже все хорошо изучено и изложено. Каталогизировано по степени запаха. И даже с примерами. Реально тот-же Фаулер прямо четко и конкретно указывает какие признаки обладают дурными запахами и что можно сделать и почему это нужно сделать(примеры из разных жизненных ситуаций почему проект потом в это упирается).

для работы с периферией используется номер (например номер UART: void usart_set_baudrate (uint32_t usart, uint32_t baud)), а у меня все мои либы используют обычно указатель на хэндл того же UART.
Что, на мой взгляд гораздо прямее, т.к. не нужны никакие if-else по номеру, а сразу usart->sfr.BRR =XX.

Ну тут можно поспорить. С точки зрения принципов сокрытия информации тут как раз лучше подходит абстракция порта до номера, а не предлагать таскать везде этот указатель на структуру(хэндл) порта. Эта структура по идее вообще должна как можно реже всплывать и находиться в кишках HALа ибо есть ни что иное как способ представления порта внутри HALa. Наружу выводится интерфейс. Просто Си не позволяет сделать это естественным образом и часто таки заставляет программиста таскать с собой хэндл, но это уже другая история... Но если хэндл пользователю либы не виден и ввели номер - это архитектурно правильное решение я считаю!

if-else по номеру, а сразу usart->sfr.BRR =XX.

опять же классики учат вначале строить систему максимально правильно(сюда входит и принцип сокрытия информации) а после профилирования устранить узкие места. Если например в коде будет встречаться какой-нибудь uart_send(uint32_t usart, char* string); и эта функция будет дергаться так часто, что упомянутый if-else реально начнет влиять на производительность то например можно будет его упразднить путем добавления функции usart1_send(char* string); где будет прямое обращение к хэндлу порта. Однако же я сомневаюсь что до этого дойдет в данном случае(ибо usart медленный).