[uquote="jcxz",url="/forum/viewtopic.php?p=4652921#p4652921"]Мне уже сказали, что "в моём коде во всей конторе никто не может разобраться". Потому как написан на си[/uquote]
Эхехех. Сегодня случайно натолкнулся я на это "никто не может разобраться":
Спойлер
Код: Выделить всё
case F_TRA:
spiC->TRBSCR = B0 | B14;
if (!(n = faz.tra.dlast)) {
if (i & 1 << SO_ER) {
faza = i += F_TRA_STOP - F_TRA << SO_n;
PingMain();
} else EndTra();
return;
}
if (n >= BURST_SPI_R * 2) {
IntDis(concat(NVIC_USIC, USIC_UNIT(nUSIC_spi), _, SRUSIC_SR(nUSIC_SR_spi_RX)));
AtomicOrI(&DLR.LNEN, 1 << nDMALINE_spi_RX);
spiC->RBCTR_b[1] = BURST_SPI_R * 2 - 1 - 1;
__DMB();
rdmaU->CHEN = (1 << (nDMALINE_spi_RX & 7)) * (B0 | B8);
} else {
spiC->RBCTR_b[1] = USIC_FIFO_SIZE;
__DMB();
}
tdmaU->CHEN = (1 << (nDMALINE_spi_TX & 7)) * (B0 | B8);
CCU_PIN_IN(nCCU_mlx1, PIN_MLX1) << EVENT_MLX_fall * 4 |
2 << EVENT_MLX_fall * 2 + 16 |
3 << EVENT_MLX_fall * 2 + 25;
Жжжжуткое месиво из magic numbers и бестолковых смешиваний обращений к регистрам из разных периферийных модулей и прикладных вычислений. Принцип единственной ответственности (и не только он один) попран ногами. Всё склеено в такой жуткий комок, который действительно невозможно разодрать. Так обычно пишут либо начинающие, либо безграмотные. Начинающие то быть может научатся, а вот безграмотные годами пишут месиво и гордятся им. Хотя гордиться тут нечем, это безграмотная позорная мешанина.
Программирование микроконтроллеров - это не только биты и регистры, но и принципы построения вообще программного кода. И этому тоже надо учиться, а не пренебрегать. Те, кто учился в ВУЗах по специальности, это прошли в рамках образовательной программы. Остальным - самообразование никто не запрещал.
Есть такой
"принцип единственной ответственности", который гласит, что функция (класс, модуль) должна
отвечать только за что-то одно. Если функция работает с регистрами SPI, то она должна работать
только с регистрами SPI,
никаких побочных вычислений какой-то переменной faza, никаких вызовов какой-то PingMain(), которая вообще черт знает что там делает, никаких вызовов посторонних модулей. Принцип единственной ответственности! Если надо вычислить переменную faza, это делается ВНЕ этой функции. Если надо вызывать PingMain(), это делается ВНЕ этой функции. Если нужно активировать DMA, это делается ВНЕ этой фукнции.
Нельзя смешивать в одной функции разные уровни - уровень работы с железом и прикладной уровень. Каждая функция занимается только тем, для чего она предназначена.
WriteSpi(GetPhase(i)); - уже лучше. (Причем, орфографически правильно не faza, а phase)
Из вышесказанного следует еще один принцип -
принцип открытости/закрытости. Он гласит, что если нужно расширить функционал, то
не следует изменять уже написанный модуль или функцию. Добавьте этот функционал в отдельной функции, не переписывая готовой. Потому что каждое дописывание готовой функции требует повторной её отладки, тестирования. Зачем переделывать работу, которая уже была сделана?
А если потом потребуется наоборот уменьшить функционал или использовать модуль в другом месте с меньшим функционалом, потребуется опять переписывать написанный модуль, выбрасывая лишнее.
Используйте
интерфейсы модулей. Взаимодействие с программным модулем должно происходить только через предоставляемый модулем интерфейс. Интерфейс - это набор функций для доступа к внутренней структуре модуля.
WriteSpi() - это интерфейс модуля Spi для передачи байта.
GetPhase() - это интерфейс модуля фазы чего-то там для получения значения этой фазы через вычисление.
Отсюда следует
принцип повторного использования кода. Он предполагает, что написанный модуль (класс, функцию) можно
без изменений(!) использовать в другом проекте или в другом месте проекта. Показанный выше фрагмент не предполагает повторного использования - в новом проекте с другим функционалом этот фрагмент придется переписывать заново. Из-за этого увеличивается время разработки, усложняется отладка и поиск багов, а структура проекта выглядит как бесформенное месиво с трудноотслеживаемыми зависимостями. Невозможно что-либо изменить в одном месте, каждое изменение тянет за собой клубок тесносвязанных зависимостей. Невозможно один модуль заменить другим без внесения правок и переотладки уже отлаженного кода. Потому что в одной функции тесно переплетены как работа с регистрами микроконтроллера, так и работа с бизнес-логикой проекта. Выдернуть, поменять, переставить что-то - задача не из легких и сопряжена с риском человеческих ошибок.
Если попросить автора этого кода быстро в режиме "надо вчера" что-то изменить в функционале, он, этот автор, не сможет выполнить работу в короткий срок. Даже если он в собственной каше хорошо ориентируется, простая замена какого-либо функционального модуля потребует внесения множества правок, переписываний и повторных тестов уже протестированного. Это противоречит принятым принципам программирования и создает множество рисков и задержек в работе. И получается всё действительно будет завязано на одном человеке, который это написал. Обычно, такой человек является самым ненадежным звеном в компании, да еще и шантажирует руководство своей якобы незаменимостью. Типа, "вот если я уйду, вы все рухните". Но как показывает практика, вместе с этим шантажистом выкидывают и все его проекты, заменяя на правильно написанные. Некоторое переходное время компания испытывает трудности, но после устаканивания о предыдущем работнике-шантажисте больше вообще никогда и не вспоминают. А если и вспоминают, то только в негативном контексте. Хреновая перспектива, однако. Такой человек никогда не будет внесен в историю компании, даже если и многое сделал. Срабатывает обычная психология.
В общем, если кому-то сказали, что "в вашем коде никто не может разобраться", то это следует воспринимать как сигнал того, что вы не знаете принципов программирования и пишите ужасный код. Вряд ли эта фраза несет похвалу. Скорее, прямой намек на то, что погромист безграмотен и генерирует весьма опасный код разового применения. И скорее, все только и ждут, когда же этот горе-погромист свалит всё-таки на пенсию. А после этого никто даже и не будет разгребать это месиво, просто выкинут всё и заменят другим, структурированным кодом, с которым можно будет быстро работать и поддерживать его без создания рисков для компании.
PS. Есть принцип "Keep it simple, stupid", что в переводе означает "пиши проще, чувак!"
