So I'm writing this Ruby on Rails app and, being newer to coding in general and not following a tutorial this time (you gotta run through Michael Hartl's tutorial if you're new to Rails), one of my biggest fears is creating a brittle and/or fragile code. I want my program to work on the tiny level that it currently operates on and then I want it to scale seamlessly when I throw tons of data at it. These are my current musings/learnings on code fragility.

Turns out, no one knows the difference between brittle and fragile code. I like DXM's reply on that thread that just says, essentially, English and code don't match up, so be flexible. What the two words DO mean is that something is not right...either your program is running by the skin of its teeth and will break if there is an influx of users/data/unexpected datatypes, or something is already, currently broken. Brittle/fragile isn't good, regardless of the meanings you choose to assign to it, that we can agree on.

Oddly, even though I can't pinpoint what exactly it means, I have come across some concrete ways to avoid brittle code. Also I'm going to stick with brittle because it reminds me of peanut butter brittle.

Test. And then test your tests. I do not understand all of the words in this article - again, I'm kind of a noob and they're at least referring to a different test framework than what I'm used to if not testing for an entirely different language than what I can write, but the principle is still good. First, write good tests (Rails is big into TDD, something that I need to be doing more of). Then, if they break unexpectedly, systematically go through your program and your logs, testing and troubleshooting your tests, and ultimately your code.

Don't bend the rules. Now listen, coding thrives on innovation and the ability come up with creative solutions. TMTOWTDI! But if you're writing a bit of code that doesn't really do what the language authors intended it to do ("but, hey, it works right?") things will eventually

Advertisement

Keep your code DRY. This is a standard in coding anyways, but it always bears repeating. Don't Repeat Yourself. That way, if something breaks you have to look in fewer spots to fix it, the fix will clean up multiple errors, and DRY code is generally more code readable and re-usable, as that post notes.

I'm sure there are more things to keep code from being brittle...but I'm a 2-point kind of guy, so I'll stop there. Drop any additional suggestions in the comments! However, as a parting shot, I was tickled to find that Urban Dictionary had a definition for brittle code.