I define fragile code as code that isn’t easily changed without introducing bugs. I think the biggest cause of fragile code is cut/paste algorithms. This is especially true for data access and processing routines.
The idea behind Object Oriented programming is that you end up creating accessor functions for all your data. It’s simple to change your data formats without breaking the program as a whole. When you don’t have an OO language, you create all kinds of methods to do your repeated work.
This is critically important for stable, readable, sane code. Functions should do something small, and do it very well. Then you can call a whole series of strong little functions, rather than cutting and pasting the same code over and over, only to wreck your day much later on.
Worked for a little while last night trying to figure out how to rotate the image on an LCD screen. Turns out the controller actually has a built in rotation ability. All the examples in the docs show a portrait LCD display being rotated to a landscape LCD display. I needed to the do the opposite. Anyway, 1 typo and several LCD controller registers later, I had convinced it to work, but with a nasty flicker. I dug around a little more and finally found where I could define “line widths” for the display memory (as in, each line of physical memory is 256 bytes, but it’s only going to display 240 of those bytes). Thank goodness the display library had already been set up to deal with virtual spans. Anyway, with that in place, it came up perfectly. Yay! It’s going to wreak havoc on the the testing routines: let’s just say the screen CRCs aren’t going to be the same. In fact, the screen CRCs might be just flat wrong; I’m not sure what portions of video memory it scans.
