Anti-Pattern and Code Smell Defined

Dictionaries I had pretty much assumed that nearly all software developers would know what I mean when I use the words anti-pattern and code smell. Over the last couple of months, I have come to the conclusion that this is not strictly true.

What is an anti-pattern?

When asking this question, I have received a number of different responses. Everyone seems to have a basic understanding, but most don’t have any clearer idea than “it’s bad code.”

To understand what an anti-pattern is, you must first know what a pattern is.
(more…)

Object Cesspool Anti-Pattern

Object pools are a common pattern in development. The canonical example is probably a database connection pool.

If objects returning to the pool are not validated, the pool can gradually fill with garbage objects, turning it into a cesspool of unusable objects.

How to Identify

The two easiest ways to identify if your object pool may become a cesspool:
(more…)

Input Kludge Anti-Pattern

As an anti-pattern, input kludge describes a poor user interface that either rejects or incorrectly handles valid input.

How to Identify

The most obvious code smell that may point to this pattern is ad-hoc input validation routines.

Look for:

  • JavaScript validation function defined directly in web page or view code.
  • Server-side validation routine defined in the presentation layer or the controller.

Example

$('form').on('submit', function(event) {
    if (!(/^.*@.*\.(com|edu|net|org)$/g.exec($('#email').val()))) {
        alert('You must enter a valid email address.');
        return false;
    }
})

(more…)

Code Smells and Anti-Patterns

NoseWhat is an Anti-Pattern?

If you know what a pattern is, then you probably already know about anti-patterns, even if you didn’t know it! In a nutshell, a design pattern is an observed good method to solve a re-occurring problem. You have probably observed patterns in your own development.

For instance, maybe you have an object that needs to be accessed by multiple threads, but the integrity of the application requires that there be no more than one instance. In the countless times that this problem has been solved in the past, most “good” solutions have taken a similar form… what we now call the Singleton pattern.

(more…)

New Home!

Crushing the Taj Mahal with One Hand

It didn’t take long for me to determine that I needed my own domain to host my blog. Now I have more control and autonomy. Since I build websites for a living, I thought I should give myself a more professional online home.

Since my day job, family, consulting and speaking take up so much time, I will be improving this site incrementally. Don’t worry, I’ll try and point out anything especially interesting as I add it.

St. Louis Days of .NET 2012

St. Louis Days of .NETCheck it out! I will be speaking at this year’s Day of .NET conference in St. Louis!

My topic is going to be centered around code anti-patterns. Why they are bad, how to identify them, and how to fix them.

Here is a deep link to my session page on the conference website: http://www.stlouisdayofdotnet.com/2012/sniffing-out-sucess-identifying-smells-and-anti-patterns-in-your-code

If you have a “favorite” anti-pattern, let me know! I might try and fit it into the presentation!

Hope to see you there!

Update: I was just notified that a second one of my presentations was accepted! I will also be giving my talk on Troubleshooting Software in Production. Now you have twice as many opportunities to let me talk at you for an hour!

Critical Blocks and Improper Lock Objects

Quick catch-up… critical application blocks are blocks of code that can only be executed by one thread at a time. Stock example for illustration:

public static class SmackTracker {
    private static int smackCount = 0;
    private static object locker = new object();
 
    public static void HitItAgain() {
        lock (locker) {
            smackCount++;
        }
    }
}

No matter how many threads call this method, the smackCount will only be incremented by one thread at a time, but this is not a post on the value and usage of thread locking…

(more…)

Order of Operations in nested try..catch..finally

Let’s dive in and take a look at some common and not-so-common exception handling arrangements.

Everyone should be familiar with the standard try..catch..finally construct:

try {
    //this code will run only until an exception is thrown
}
catch {
    //this code will run only IF and exception is thrown
}
finally {
    //this code will run always AFTER the try and/or catch blocks have been executed
}

Here is a less common arrangement. When might this be appropriate to use?

try {
    try {
    }
    catch {
    }
}
finally {
}

Now let’s look at some concrete examples. Consider this code snippet:

(more…)

Exceptional Introduction

There has been a lot of discussion over the years about when and how to use exception throwing and handling. The general consensus seems to shift every once in a while. The performance of exceptions is not the primary purpose of this article, but I felt the need to discuss it in order to truly address the role of exceptions in software troubleshooting.

Exceptions are Expensive, like Store Brand is Cheap

Maybe the best way to breach the topic of exception performance is to simply give you a short list of axioms that I believe to be true.

1. Exceptions are expensive

It has been proven many times that there is additional cost associated with constructing and throwing an exception. This seems to be exaggerated in managed applications (.NET, Java, etc.). That being said, this extra “cost” of constructing and throwing an exception would only be noticeable in time-critical real-time systems, or if they are used excessively. That brings me to my next axiom…

(more…)