Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

When you're discussing a system or a code base, when you use the adjectives 'brittle' or 'fragile' to describe it, what's the difference between those two terms?

share|improve this question

closed as primarily opinion-based by gnat, Kilian Foth, Bart van Ingen Schenau, GlenH7, John R. Strohm Feb 9 '14 at 15:09

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

To me, they are synonyms. – PersonalNexus Jan 22 '12 at 6:10
If any true definitions are in material science: brittle material is "hard" (withstand compression) but "not tough" (lack of ductility). Fragile is something that has almost no strength. In software context however, there is no specific meaning - just a good way to tell your code sucks! – Dipan Mehta Jan 22 '12 at 8:46
Context please. I use quite a few adjectives to describe my code, that doesn't make them established terminology. – Yannis Jan 22 '12 at 9:16
I see brittle used quite alot to describe tests. "This unit test needs improving cos its particularly brittle. Its testing unstable/wrong aspects of the test-subject.". I spose fragile is just as good a word, but I don't see it used in that context as often. – JW01 Jan 22 '12 at 11:28
@JW01: - how about now :)... and that's not just random blog, that's from xUnit Test Patterns Book. – DXM Jan 22 '12 at 18:58

3 Answers 3

up vote 2 down vote accepted

As I hear them used in reference to code, brittle refers to inflexible or correct in a narrow scope, but stable if left unaltered and used in a consistent manner, often something that really only works exactly the way it is currently used.

Fragile can refer to all sorts of things being easy paths to failure and is generally not stable even in a stable environment.

Often it is a ROI call on improving something brittle, but fragile usually has to be fixed regardless.

share|improve this answer
-1: DXM's answer is way more correct. – naiad Jan 23 '12 at 2:34
I don't necessarily disagree with his assertions, that just isn't how those phrases are used in my circles. I have worked in a lot of shops that are not primarily IT. Brittle the way it is used above is often acceptable, even specifically requested, fragile as above is not. – Bill Jan 24 '12 at 3:12
I agree with this distinction. A brittle object is one that cannot be readily changed; a fragile object is one that can be readily broken. Likewise with code. Using a piece of code like (ch >= 'a' && ch <= 'z') ? ch-32 : ch to convert ch to uppercase is slightly brittle (it would have to be completely rewritten to work with anything other than standard ASCII) but robust. By contrast, code like do_command[(ch & 31)-1](), where do_command is an array of 26 function pointers would be both brittle and fragile. It would execute commands in non-case-sensitive fashion, but would... – supercat Jul 11 '12 at 16:41
...potentially malfunction very badly if ch is anything other than an uppercase or lowercase letter. In some cases, it may be appropriate for a program to error-out if an invalid command is received (e.g. from a computer-generated script file) but executing a random function pointer is not the right way to do that. Parting thought: diamonds are brittle, but that does not mean they are fragile. Talc is very fragile, but that does not mean it is brittle. – supercat Jul 11 '12 at 16:43

My own definition would be that brittle code was code that tended to cause run time problems, such as random crashes, and fragile code worked OK at run time but that is easily broken by simple changes in the code.

Of course, as DXM pointed out, this is subjective.

share|improve this answer

NONE -- There, I said it.

This one of those cases where engineers attempt to assign very specific labels to something subjective. The other day I got into an argument with another member because in my mind I didn't associate "open issues" with "missing unit tests". We really need to stop treating English as a programming language where every word/phrase has exact, immutable meaning. Instead, learn to treat the language as a vague and imperfect medium of information transfer and be adaptable in your interpretation.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.