Code smell: it's that funky aroma that you notice when looking at code that tells you something's probably wrong somewhere.
Wikipedia has a list of common code smells; Jeff Atwood provides a more complete collection. And while some of these apply to Clarion programming, I think it's time we had our own list.
To kick things off, here are some of my least favorite code smells:
- Short, cryptic labels. Man, this drives me crazy. I know some Clarion coders don't like to type, but we have code completion now.
- Short, cryptic file names. DOS 8.3 is so last century.
- Huge chunks of code in embeds. The more lines of code, the bigger the reek. If you're trying to do something complex, you should probably be pulling it out into a source procedure or a class/set of classes.
- Dependence on black box products from unreliable vendors. Use of black boxes period is a cause for concern; it's always better if you can get source code.
- Use of implicit variables. I really wish these had never been put in the language. Being able to declare stuff inline is great; the problem is that spelling mistakes don't trigger compiler errors.
- Ignored compiler warnings. It's easy to let these pile up, but they're warning you of potential problems. Take heed.
- OMITs across embeds. This bit a lot of folks in the Legacy -> ABC migration. Also Clarion doesn't reliably generate routines in the same order, so depending on how you use OMITs you could remove code you actually want.
- Copy/paste code. Not only does this make maintenance more difficult, it suggests coder inexperience and/or laziness which is a strong indicator of other problems in the code base.
- Circular dependencies between DLLs. Because DLL unloading is indeterminate this can cause GPFs. But it also indicates that there's no good oversight of the application architecture.
What does bad code smell like to you?