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

I think it pretty much boils down to experience and intuition.

Answer 2

I ran the Eclipse Metrics plugin.

When you have many, MANY methods with cyclomatic complexity scores of well over 20 (one was 66...) and regularly see methods with dozens of parameters or hundreds of lines of code, you know something has gone wrong.

It doesn't tell you everything (metrics never do), but when you start seeing numbers like that, it gives you a place to start looking.

Answer 3

McWafflestix has a lot of good points at the organizational level. A dysfunctional software engineering organization will make it nearly impossible to produce good code, if only for simple pragmatic reasons such as lacking decent tools and automation.

Even with a functional organization and good tools, however, anti-patterns can grow on you. Some characteristics I look for are below, with the rules of thumb I use in parentheses.

Some signs:

• In OOP, extremely deep object hierarchies (more than 3 levels)
• Copy-and-paste code that appears multiple times (more than 3) OR code in multiple locations that performs substantially the same function
• Copy-and-paste code with minor/subtle changes that cannot be easily/sensibly parameterized

I also tend to look for areas in the code which are not intuitive, readable, (insert favorite adjective here). This speaks less to code quality and more to your team's ability to work together effectively. Over time, a team's codebase usually picks up a dialect - common semantics and vocabulary for method and variable names, informal conventions about ordering methods or operations, etc.

Ensuring the consistency of that dialect can help significantly, especially when one team member has to work on a segment of code that had, until that moment, been maintained by another person. When code begins drifting substantially enough off the common dialect, that can be a sign that a design anti-pattern is emerging.

Answer 4

Here's the giveaways:

• Lots of side effects
• Lots of regressive bugs
• Very difficult to test
• Doesn't fit in with other libraries
• Difficult to refactor
• Difficult to extend.

Come to think of it, this is pretty much any bad code.

Answer 5

Sorry to add to this late - I just wanted to contribute that in my experience a lot of cruft in the main codebase seems to indicate that no-one has really cared for it. For instance you have classes that seem to do something but you find they have been superseded by other development and are never called, having investigated at length.

Answer 6

My personal pet peeve in this regard is a large number of "dummy" or "mockup" forms. Wherein someone creates a mockup of the form, then creates a new mockup when the requirements change, then creates a third mockup when they stabilize, and then, finally, makes the real form. At the end, you wind up with file names like

-frmAddUserWizard
-frmAddUserWizardv2
-frmAddUserWizard_MOCKUP
-frmAddUserWizard_OLD

And ALL of these forms are accessible from the application, because we need to display them to take a screenshot to show the user! At a glance, its impossible to tell which of the forms is the real one (tip: in the above example, its the second entry). But nobody wants to delete the old code, because they represent work that they put in, and they don't want to part with it.

edit: This can also happen when forms get re-used in the application, and "copypasta" inheritence is used.