Как писать код без багов?

Не оптимизируйте код заранее. Идея усложнить код ради его ускорения почти всегда ошибочна. Исключение возможно только в том случае, когда именно этот участок код “тормозит” так, что это уже заметно на уровне продукта или бизнеса. “Пессимизировать” код тоже, конечно, не нужно, из двух версий, одинаковых по сложности и по объему кода, выбирайте более быструю. Из этого есть важное следствие: нельзя дублировать данные и нельзя кешировать результаты вычислений там, где этого не требует во весь голос производительность. Больше половины структурных багов возникает из-за того, что “разъехались” кэш и реальные данные, причем еще и отлаживать такое обычно адски сложно, потому что в момент собственно “разъезжания” никакого бага еще не видно, он проявится потом, когда ставить breakpoint-ы и проходить исполнение по шагам уже поздно.

Не смешивайте алгоритмы и другие технологически сложные участки кода с бизнес-логикой. Выразительности современных языков программирования вполне достаточно для того, чтобы, скажем, графический движок компьютерной игры ничего не знал о ниндзя и вертолётах, функции работы с БД в CRM-системе не знали слов “счёт” и “клиент”, и т.д. и т.п.

Стоит выкинуть из головы все ООП. Единственное полезное, что в императивные языки пришло из этой идеологии - модификаторы private. Иерархии классов это зло, наследовать реализации нужно себе запретить. Наследовать можно интерфейсы, и то не слишком много уровней. Агрегация почти всегда лучше наследования. Большая часть классических “шаблонов проектирования” уже либо устарела, либо нашла поддержку на уровне языка.

Каждая лишняя строчка кода это зло. Там, где это вообще возможно, не стоит пользоваться чужим кодом, который вы не прочитали и не поняли от и до. Это касается в том числе и широко известных библиотек и фреймворков общего назначения. Чем меньше кода (включая и тот, который пишешь сам, и тот, от которого зависишь) - тем лучше.