//TODO: Create Blog Title » Unmaintainable Code

Five Steps to Making Fellow Developers Miserable

Josh — Thu, 13 Aug 2009 12:00:46 +0000

1. Setters that do more than SET

All property setters should validate their input and set the value of other properties. This will remove the burden of validation from other developers.

private string _id;
public string Id
{
  get
  {
    return _id;
  }
  set
  {
    _id = value.ToString();
    _AnotherPropertyValue = value.ToString();
  }
}

private string _AnotherPropertyValue;
public string PropertyValue
{
  get
  {
    return _AnotherPropertyValue;
  }
  set
  {
    _AnotherPropertyValue = value;
  }
}

Workaround: Property getters and setters should only save and return values. Getters and setters should not validate against null, perform regular expression checks, or typecast. Additional logic can take place in business logic classes. Setters that do more than set also cause issues during unit testing. What goes in, must come out.

2. The Golden Hammer

Whenever implementing something new, remember the last successful (or similar) experience and reuse. There is no doubt about it. What worked for you in the past, will continue to work for you now.

Workaround: With the Golden Hammer approach, your solution is the hammer and every project you come up against is a nail. If you find yourself trying to implement an exact replica of a solution that you built in the past, chances are that you will miss some requirements or pigeonhole yourself into somewhere you do not want to be. Instead, step back, learn what the functionality of the system must be, and compare/contrast the differences between past experiences.

3. Swiss Army Class

Just as in bloated class, minimize how many separate classes your code must deal with. If you know all of the different functional areas your application needs to cover, extract them to an interface. Using interfaces will allow you to switch out the implementation types without changing your code. Just make sure that you keep your number of implementation classes low so that it is more maintainable. If necessary, make the lone class implement every interface in the project.

Workaround: Focus on keeping the implementation of your classes very specific to single units. If you feel the need to implement multiple interfaces to create a hybrid of a few simple interfaces, this is perfectly acceptable.

4. Yet Another Damn Layer

Encapsulation is one of the greatest features of object oriented programming. If you can find a way to make existing code more generic so as to make it easier for implementation efforts (and less code writing!) you should do so. Create a generic interface that will take care of defining all of the different functionality in one call.

Workaround: Encapsulation should be used to hide any of the internal mechanisms of a separate software component. Good examples of this are code that is used to perform common tasks such as logging, serialization, or instrumentation metrics.

5. Unit Testing and Stale Data

Since testing is usually a hassle to go through, try and spend as little time doing it as possible. It already takes long enough to set up the tests and the test data. Try not to worry about clearing out the test data since it is only in the development environment.

Workaround: Unit tests should take care of setting themselves up and tearing themselves down. Unit testing should and can be a full-time job position as it should account for every possible variation of data input and output that can occur. If you can not write your unit tests to clean their test data up, then they should use in-memory data providers so as not to impact any other users in the same environment.

* DISCLAIMER * Please note that my views are that of the Workaround type method and this article is meant to prove humor at what can go wrong when unsafe practices are used. Also keep in mind, I’ve probably done each and one of these plenty of times in my career.

Code-smell: Whack-a-Mole

Josh — Mon, 10 Aug 2009 21:00:52 +0000

It’s 4:00 on Friday afternoon. Do you know where you want to be?

Definitely not at work. About fifteen minutes before you decide to log off and bolt out early, a critical defect is logged with your application. Your data import isn’t working correctly and it is losing content during execution. The client, and project managers stress to you that this is a must fix issue as the testers cannot continue until your content is valid.

You grumble, sit back down, and pull up the code to inspect the issue. Ten to fifteen minutes later the fix looks relatively easy. Excited that a resolution was identified so fast, you settle in and begin the fix. Shortly after the fix is in place, you test to make sure everything continues to work as is…. then you gasp as you realize what happens next: it is the Whack-a-Mole bug.

whack-a-mole bug n 1. a defect that reappears throughout your application in multiple locations and is difficult to get rid of no how many times you attempt to get rid of it

Related Code-smells: DUPLICATE CODE, SHOTGUN SURGERY

Most often this code smell is a by-product of Shotgun Surgery. While it may seem easy to copy the same validation code used during data-in to data-out, you know it is not the right choice. Now later on, that specific code had particular issues and it must be fixed in more than one place.

Five Steps to Making Fellow Developers Miserable

Josh — Thu, 23 Jul 2009 12:00:59 +0000

1. Long Method

Short methods specific to single units are bad. Try to limit the number of methods in each class. This will ensure that each method is as long as possible.

Workaround: In order to prevent long method from happening, I recommend limiting the length of your functions to 30 lines or less (40 including exceptions). Focus on keeping your functions less then one screen’s length. Try bumping up the font-size of your IDE so that a lot less code fits on the screen.

2. Out of Sync Comments

Just like you learned in college, comments are the best form of documentation. Comment blocks are better. Provide details about every line of code and include pre-conditions, post-conditions, and expected exceptions. Comments are important because they help other developers calling the code understand how it works.

/// 
/// Saves data into database
/// 
/// 
/// Save Data opens up a SqlCommand object and calls the 
/// sp_SaveUsers stored procedure to save a user object.
/// 
/// 
/// User object must be created. sp_SaveUsers must exist in SQL server
/// 
public void SaveData()
{
//Get Connection String
string connectionString;
SqlConnection connection = new SqlConnection(connectionString);
//Open Connection
connection.Open();

//Create Sql Command call “sp_SaveUsers”
SqlCommand cmd = new SqlCommand();
cmd.Connection = connection;
cmd.CommandText = “INSERT INTO USERS (userId, userName) VALUES (?,?)”;
cmd.CommandType = System.Data.CommandType.TableDirect;

//Add Parameters for Stored Proc
cmd.Parameters.Add(u.ID);
cmd.Parameters.Add(u.Name);

//Execute Command
cmd.ExecuteNonQuery();

//Close connection
connection.Close();
}

Workaround: If you are going to write comments, specify the problem that your code solves, not how it solves it. Think of the last time you picked up a book at the store and read the back. Would you have wanted it to tell you what the story is about, or how the plot is laid out? If you change the implementation (bug, refactor, etc.), the comments can remain the same. Try and get away from code commenting all together by writing self-documenting code. For examples read Jeff Atwood’s Coding Without Comments.

3. Bloated Class

Enforce a limit to the number of classes allowed in the codebase. To reinforce this, place all logic into one big blob class. With this class you are the ultimate tool that can do anything. The more classes you have, the more source files you maintain. More source files increase the compile time of your project.

Workaround: Follow the Single Responsibility Principle (SRP) to keep the implementation of your class specific to its’ purpose. Classes should only have one reason to change, and no other components of that class should be affected during that change.

4. Classes that are “involved”

The more that each class knows and relies on another class, the better your code is as a single unit. New developers will need to understand every class in your solution because one change creates a ripple effect throughout the system. Dependency hell is much nicer than it sounds.

Workaround: Develop code that is loosely coupled. Loosely coupled code is attained by making each class units that do not have knowledge of how other classes work. This creates more flexible design. Do not overkill as too much can lead to unneeded code complexity.

5. Developer Ego

The smarter a developer and the better coder that they believe they are, the better the code output. The only one capable of creating awesome code is one who looks at the world as one complex problem. Try to avoid breaking it down into simple smaller problems, otherwise any regular programmer is capable of doing your job.

Workaround: Give the developer the smack-down.