Некоторые несложные принципы я изложил ранее. Это не только мое мнение, это мнение множества грамотных, образованных программистов, которые не только умеют битики в регистрах щелкать. Эти и другие принципы изложены в книгах и учебниках, обсуждаются на тренировочных задачах (кейсах).
Почему следует придерживаться принципов структурированного написания кода? Во-первых, хорошо структурированный код легче редактировать в процессе написания. Во-вторых проще находить баги, проще отлаживать. В-третьих, (и на мой взгляд, это самое главное) программные модули кода можно без их изменения использовать в других проектах, ускоряя их разработку.
Чтобы это было возможно, следует соблюдать остальные описанные ранее принципы.
Принцип единственной ответственности - программный модуль (класс, функция) затрагивает только то, для чего предназначен.
Для примера, функция WritePort(data) не должна делать ничего, кроме записи в выходной порт переменной data. Она не должна вызывать внутри себя никаких там Dma, никаких посторонних обращений к какой-то PingMain(). Если такие обращения нужны по алгоритму работы, то сделайте эти вызовы ВНЕ функции WritePort(). Если нужны какие-то доп.условия выполнения, запишите их вне функции. Если нужны вычисления посторонних переменных, вычислите их снаружи.
С другой стороны, если для записи в порт нужно прибегнуть к помощи иных функций, таких как WritePin(value), то эти функции могут вызываться, поскольку цель у них та же самая. Так же внутри WritePort(data) можно например разложить переменную data побитно для WritePin(value). Это нормально. Но НЕ нормально накладывать посторонние условия и вычисления, типа if(data==3) PingMain() и тому подобное.
И тогда это функцию вы сможете использовать в другом проекте или даже в другом контексте этого же проекта.
В показанном ранее примере кода нарушен принцип единственной ответственности, поэтому я и написал, что сиё поделие пишется либо новичками, либо безграмотными погромистами, которые просто ничего не знают.
Есть другие принципы, они чуть более сложные и они ближе к объектно-ориентированному программированию.


