When do you know you're dealing with an anti-p

Question

I'm looking to see how other programmers find anti-patterns, "code-smells", etc.

In particular, what things start setting you off when you're looking at code that tells you, something has gone wrong here?

I'm not looking for a list of different patterns like this post. I want to know how you've found such things in code bases you've worked on in the past.

Answer 1

When the comments have the word "trick" in them, as in "A trick for figuring out which customer to return when we don't know which one we are supposed to use.

Seriously, I think it's like obscenity: You'll know it when you see (smell) it.

• code with lots of bugs logged against it, but the code itself has not been updated in 3 years or more.
• database structures with comma-delimited values within a single column
• code with no comment, no meaningful names, and and lots of numbers
• code where there's only one guy or gal who is allowed to maintain it.

Answer 2

Anti-patterns are identifiable the same way patterns are; they're both descriptions of a general technique that "smells" the same no matter where you find it. So when you see a class that imports most of the available namespace, has 30 000 lines, and has more commits than the rest of the codebase combined, chances are you're looking at a God Object.

The important thing to note, I think, is that (as McWafflestix and Christopher point out) bad code is like obscenity. You know it when you see it.

Answer 3

Conflicting Styles.

When you read through the code, you quickly figure out who wrote it- Joe always uses state machines, John always uses event driven callbacks, and Fred is Mr Two-line-function.

If their style reflects the needs of that part of the program, great, but when it reflects dueling architectural ideas, with no one in particular winning, then you know the code really smells.

Answer 4

Actually, the first and most clear warning sign that there is something severely wrong is not at all in the code; it's in the organization. Organizations that display clearly toxic or bizarre traits tend to have codebases that show antipatterns. It's uncertain as to whether the codebase being messed up is the result of the antipattern, or the organization being messed up is the result of the codebase being messed up, but the upshot is that the easiest way to notice an antipattern is to see something going horribly wrong in the organization.

Sometimes, it can be a while before you get deep enough into the codebase to determine that the codebase is complete spaghetti; usually before that, though, you'll find a coworker who explains with a wry comment that "you don't want to open Pandora's box by trying to change anything". Long work hours can be another indicator of antipatterns at work; so can "guru syndrome" ("Bob's the guru; he's the only one who understands the system"). These things all show up as organizational problems far before you end up seeing them in code.

Since there seems to be a desire to get some metrics as to what a dysfunctional organization is, here are a few indicators (by no means exhaustive):

• Massively disgruntled workers
• Timekeeping obsessed management
• Shoehorning ("Golden hammer" antipattern)
• High turnover rate among engineers
• Bad ratio of dev / test (either too high or too low is an indicator)

These aren't really metrics; they're just really warning signs. It really comes down to personal experience to know what constitutes "massively disgruntled" versus "mildly disgruntled", etc.

Answer 5

-Whenever asking about a section of code/module produces a response of "Oh, XXX did that."

-Whenever changing a section of code produces a reaction of "Yikes, I can't believe you changed that."

Answer 6

One of the things I notice fairly quickly is the amount of historical comments and commented out code. This is typical of developers that don't use or don't trust source control.