Primitive Obsession

Primitive data types are the building block of any data representation. So, practically anyone can represent any data with primitive data types. We study programming logic by using primitive data types in school. So, everyone in software development world is comfortable to use primitive data types. It's easy to use, fast to execute and uses minimum memory.

But in object oriented programming using primitive data type to represent data makes huge complexity. Using primitive data types is the main reason to have code smells in the code. It is one of the main reason for duplicate code, large class and long method code smells. In most cases using primitive data types breaks most of the design principal.

If you feel that something is very wrong in your code, code smells like duplicate code, large class, long method all together then try to find if there is any primitive obsession exist in your code. If you find it and refactor the primitive obsession then that would help you to easily refactor other code smells.

Primitive obsession code smells is not limited to data types provided by any compiler. An object like XmlBuilder, StringBuilder, HashTable , Dictionary, Lists are also creates primitive obsession. So, use all these objects intelligently to avoid primitive obsession.

Dead Code

We all love our code. So, we usually don't delete our code even if it is not referred anywhere in the system. Sometimes we comment the unused code. May be we will need that soon. All these are dead codes. Because these codes are never used and in most cases it will never be used. To manage the history of our code there are some other tool available. Source Control can archive all our code. Why do we need to keep the dead code in the working code? We can find any version of our code in the source control.

If a system have some dead code then there is a chance of spending time and effort while refactoring some production code. You might have to re-factor in dead code because compiler would complain in the dead code because of your refactoring. It becomes worst if you fail to identify the code is a dead code or not.

So, delete your dead code even if you spend big effort and created a beautiful logic. Don't hesitate. You may come-up with a better idea if you solve the same problem again. If you feel that the you might need the code in future then add a label in your source control. But delete the dead code.

Technical Debt

We always write code which needs to be improved to insure better maintenance and readability of the code. That becomes the Technical Debt. It matches exactly to the financial process we used to follow. We always face in a situation where we need financial debt. From our experience we all agree that if we don't manage our debt in time we might face in a situation that we had to pay a huge interest. It happens in software. If we don't give enough time to minimize our technical debt then we face in a situation of project failure or redesign completely.

It's better if we agree that we always make technical debt, hence we have to minimize it regularly. Minimizing the technical debt should have equal priority as developing new features or fixing bugs.

So, learn to minimize technical debt and that skill will make you a real software professionals.

Long Method

A method is not easier to read or understand what it is doing. It has nothing to do with the size of the method. But if the size of a method is huge then obviously it is not easier to understand what it is doing. Naturally shorter method is easier to read. So, try extracting more shorter method to get rid of the long method.