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.