7 Programming Anti-Patterns

Things to unlearn as you move from CodeNewbie to Developer

Do you know “Spaghetti code”? The code base where everything lies everywhere and no one knows where what starts and where things end. It sounds like a plot for a project to end in a boom. But there are other equally scary anti-patterns you must avoid to run a successful project and to set yourself as an experienced developer.

Anti-patterns are bad programming practices. Every programmer has their style. Certain styles would cause more harm to the codebase than good.

Knowing, Recognizing, and steering away from anti-patterns will set you up for a good start in your Software Development journey.

1. Copy-Paste(Voodo) programming

Copying text word-by-word is a practice writers use to develop their writing style. As a Python trainer, I have strongly vouched for copy-pasting code as a way of learning programming patterns and idioms.

That is great when you are practicing. The problem arises when you bring this practice to work. E.g., when I was a newbie developer, I copied a piece of code to read files from stackoverflow and played around with it, and it seemed to work all fine until I gave it some real input and my system froze. I did not account for processing large files. The program loaded the whole file into the memory and took over my system.

Blindly copy-pasting code without understanding the crux of it will do more harm to you and the system you are building.

So, what is the alternative? Should you never copy-paste from Stackoverflow?

How to Copy for Practice?

1. Understand the problem, write it down
2. Find a solution that you find useful
3. Copy-paste it into your code editor
4. add comments to each line depending on your understanding
5. Add print statements to prove your understanding is right
6. Run the code
7. Validate your assumptions
8. If the code doesn’t solve the problem, tweak it
9. Once the code works, make it better — easier to read, test, and optimize for space and time

How to Copy-Paste at work?

When copy-pasting at work, see how the code interacts with the rest of the system.

• Does it solve the problem you’re trying to address?
• Does this hold good for all test cases?
• Does the code style match with the rest of the codebase

2. Cargo Cult programming

It’s Friday evening. Your customer has reported a high-priority bug. Every alert is going off on slack. The management wants a fix ASAP. You don’t know the root cause of the bug, but you know adding an if statement will suppress it “for now”. That’s cargo-cult programming.

Including code or program structures that serve no real purpose or understanding of the underlying problem by trial and approach is called Cargo cult programming.

It might sound a lot like Voodo programming, but the focus here is on viewing solutions clearly as a larger part of the system rather than whether it works or not.

2.1 Cargo Cult Software Engineering

Cargo cult software engineering is when you adopt a SE practice based on its popularity or mandated as “best practice” without understanding the reasoning behind it.

How to Avoid Cargo Cult Programming?

• Know the system before making changes to it
• Ensure quick fixes are patched in only after the bug has been identified
• Ensure to make educated decisions about incorporating practices
• Incorporate code review and pair programming in your development practice

3. A Big Ball of Mud

A big ball of mud is a software system lacking perceivable architecture. Although undesirable from a software engineering point of view, such systems are common in practice due to business pressures, developer turnover, and code entropy. They are a type of design anti-pattern.

To Avoid Ball of Mud

1. Understand the problem at hand, write it down
2. Split them into individual solvable pieces
3. Think of these pieces as individual functions
4. Merge repeating sections into a single function. Always DRY (Do not repeat yourself)
5. Solve the individual problems(use stackoverflow only here)
6. Write tests for the individual pieces and how they work together

A codebase is already a big ball of mud that needs refactored. Make a deal with your product team and get some time on this engineering effect. It will help you fast-track future development.

4. Code/Design smell

Spinning up a set of features without proper design often results in a Code/Design smell. Poor design decisions will leave the system fragile and challenging to maintain.

Adding code to an already flawed design will result in the accumulation of technical debt.

One of the easiest ways to identify code smell is to look for

• Functions doing more than one task leave room for design smell.
• Classes/Modules that are too long
• Code is not segregated into functions and modules
• Code not testable

5. Ego Programming

Ego programming is when a programmer infuses their programming style as opposed to the one adopted by the organization because they have done so.

E.g., In Python, one-liners are fancy but tend to make life difficult for other developers.

When the whole Python world follows snake_case for naming functions, it won't hold good for one person to use camelCase only because they come from JS.

There is no harm in developers trying to infuse a change that will improve the lives of other developers. Whenever such change is incorporated, certain checks should pass.

• Is the code readable?
• Is the code modifiable?
• Is the code testable?

6. Golden Hammer

Using one solution to every problem since it was proven successful in the past. Just because one tool, solution, or hack worked for some problem, it won’t work for all problems.

Google might invest a whole SRE team to support the scale of millions, but when it comes to you, all you need is an alerting system ensuring you’re paged when things go down.

7. Boat Anchor

You know how project managers are; they will come back with more features. I have heard more than one tech lead mentioning this.

Adding more code to support a feature that you might need in the future is a boat anchor problem. It increases complexity.

I already hear you saying, “But I know my PM they will come back with features”. In that case, leave in abstractions, not the actual logic.

8. Dead Code

Have you ever come across a function where no team member knows what it does, but it works and is referred to everywhere. That’s dead code because

1. no one knows how to change/fix it.
2. One day, one tweak, and it’s going to make the system dead

Fixing Dead Code

1. From your POV, write down what the code does in a text editor line by line
2. Add test cases to test each line of the code
3. Run the test cases one by one as the test passes, and add a comment next to it

Special Thanks to Bowrna and Abhishek for proofreading the blog

Originally published at https://thelearning.dev.