Wednesday, July 28, 2004
Code Smell
Warn Cunningham's Wiki is a treasure trove of interesting terms. Here's one I hadn't heard before: A Code Smell is a hint that something has gone wrong somewhere in your code. Use the smell to track down the problem. Note that a Code Smell is a hint that something might be wrong, not a certainty.
A Language Smell is a Code Smell that occurs due to the inability of a programming language to express a concept cleanly. Sometimes called an "idiom" or a "pattern." (Not all patterns are like this, but some are). An example of a Language Smell is explicit memory management vs garbage collection.
In both cases, smell isn't being used in a pejorative sense (e.g. this code stinks!) I think the idea is that you get a whiff that something's wrong. Even boredom can be a smell.
On a related note, I think it's interesting that both code generation and usage of runtime reflection are both "smells". In some cases, for example generating remote procedure "stubs", these are the two most popular approaches that are available, either static generation of stubs before deployment or runtime reflection to give the same behavior as generated stubs. Both approaches have issues. Runtime reflection is more elegant but has runtime costs that, as I discovered recently, can be more expensive than you'd like, even when used sparingly.
A Language Smell is a Code Smell that occurs due to the inability of a programming language to express a concept cleanly. Sometimes called an "idiom" or a "pattern." (Not all patterns are like this, but some are). An example of a Language Smell is explicit memory management vs garbage collection.
In both cases, smell isn't being used in a pejorative sense (e.g. this code stinks!) I think the idea is that you get a whiff that something's wrong. Even boredom can be a smell.
On a related note, I think it's interesting that both code generation and usage of runtime reflection are both "smells". In some cases, for example generating remote procedure "stubs", these are the two most popular approaches that are available, either static generation of stubs before deployment or runtime reflection to give the same behavior as generated stubs. Both approaches have issues. Runtime reflection is more elegant but has runtime costs that, as I discovered recently, can be more expensive than you'd like, even when used sparingly.
RSS 0.92 Feed