What is really BAD about bad code

WHAT is BAD code?

In programming we all come across GOOD code and BAD code. CODE will be BAD if it has the below traits:

• Long methods and longs classes doing more than one thing. Violation of SRP principle.
• Lot of nested if-else loops.
• Repeated code across the project code base.
• Not using the best algorithm for the purpose.
• When migrated to latest framework not using latest features (which are usually more optimal)
• Not enough comments to explain WHY the code is something than just WHAT it is doing.
• etc, etc… (so let’s stop here.)

WHAT is really BAD about bad code?

As knowledge of the developers working on the project improves and also with latest frameworks released, what was looking GOOD code a few months back will start to appear as BAD code or not so GOOD code.

Developers start using improved programming knowledge and domain knowledge to write any new piece of code. But we are bit hesitant to touch any existing code to improvise it. If we keep such existing bad code longer in the project code base, I think the new developers joined the project or the junior developer in the team tend to repeat that code even while developing new business functionality.

So overtime BAD code will get repeated more with time.

Now let’s justify the blog post title, “What is really BAD about bad code”.

I think as a developers in the team, if we don’t take time out to replace the bad code in the project source code , that is really bad about the bad code.

Approach to remove bad code

The easy solution to replace such bad code is to make steady progress every day to improve one small piece of code. Identify the bad code, make a small change, test it and check in. If all the developers get into this habit, the code will keep improving with every passing day and your project source code will always remain GOOD code.

things to be of aware before start using a method

While programming, we often use methods from the framework (.NET, JAVA), from other third party vendors packages /assemblies and also from in-house libraries written by your fellow developers. You need to understand more than the mere functionality of the methods in helping you and your team to reducing defects in the software product.

Below points will spread some light on things to be aware of before start using a method.

1.Learn about exceptions a method can thrown at you

If you look at documentation of any methods on MSDN for .NET methods, you will most probably see a section describing about exceptions the method can throw. So your exception handling logic should handle all the relevant expected exceptions.

System.Data.SqlClient.SqlConnection dbConnection = new SqlConnection(DatabaseConnectionString);
dbConnection.Open();

When you mouse over a method in visual studio, it displays the exceptions that the method can throw; provided the author of method has written Exceptions comments.

On the above example, while opening SQL Connection, the Open() method displays it can throw 2 exceptions of 2 types. So developers need to take note of those exceptions and handle those exceptions as required by your application.

You can also add Exception comments to your own methods in your application code base. One such sample is below; the method can throw InvalidOperationException as documented in the method comments.

/// <summary>
/// Process the user action
/// </summary>
/// <exception cref="System.InvalidOperationException">When internal state is not valid.</exception>
public void Process()
{
  // Method logic which can InvalidOperationException

}

2. Know whether method call is blocking or not

It's important to understand whether the method you are going use is blocking in nature or not. If it's a blocking call, the method isn't going to return until its complete. If this isn't something desirable, look for its async version[i.e, BeginX() and EndX()] methods.

3. Know dependency of the method

The method you are calling might be getting some configuration data from configuration files, etc. In that case, what the method is going to read should be present in your application configuration file. Otherwise the method mightn't function properly.

So make it a point to read the method documentation thoroughly to understand its dependencies.

4. Understand Thread Safety of the method and need for thread safety in your application

If you are using multiple threads in your application, you need to pay special attention to any new method you are going call. To have thread safety, you need to ensure the methods you calling are also thread safe. If not you need to synchronize the threads using thread synchronization technique such as lock statements.

You can refer singleton design pattern implementation GetInstance() method on how it is achieving thread safety using lock statements.