Software Craftsmanship - Code Smells - Dispensables

Editor's Notes

• #2: This presentation is continuation to “Software Craftsmanship – Code Smells_Introduction”. Here we will cover the first category of code smells – “Dispensables”.
• #3: How do we know that code we have written is good or bad? Is it a subjective opinion or is there any metrics to determine whether it is readable/extensible/maintainable? Luckily for us, there IS A METRIC! When you go past a garbage can, you tend to block your nose, as the foul smell is almost unbearable. When there is something wrong with the code, we say there are certain elements in it which stink, making the whole code stink as well! These stinky elements are referred to as code smells. Now, when it comes to real life objects, the sense of foul smell is an innate human tendency. But when it comes to code, we need to teach ourselves to identify these code smells. In other words, we need to develop a nose to identify foul smells in the code. And this ability can only be developed when you are relatively young (new to development). As soon as a hatchling starts flying, its mother teaches it to hunt, for it won’t survive in its adulthood without the ability. The same goes with the ability to smell stink inside the code. It becomes harder and harder to develop this ability as we grow further into software development without it. For it is easier to learn than to unlearn. Writing a code with wrong practices is more dangerous than not writing the code at all! IT IS VERY IMPORTANT FOR ANY YOUNG DEVELOPER TO DEVELOP A NOSE FOR THESE CODE SMELLS! There are broadly 5 categories code smells are divided into. We are covering the first category here: Dispensables
• #4: How many of you have stacked up your room with endless items that you never use? Almost all of us right? When we want to search some item in the room, say a book, how many of us have suffered relentlessly before finding it hidden somewhere below a huge stack of these unused items? All these items are dispensable but we never get rid of them thinking they might be useful at some point of time. This makes searching even the useful items a difficult task most often than not! The same goes with your code. We tend to keep hundreds of lines of codes, methods, classes etc. in our software that are of no use in reality! All these elements even if removed, would not affect the working of the software in any way, yet still find a place in our code! All these items fall under a category of Code Smells called Dispensables! Lets see each of these in detail!
• #5: When we talk about writing a readable, well understandable code, the first instinct of any naïve developer is to embellish the code with comments! For every few lines of code (and sometimes for every line!), you will see a long comment written along explaining what that piece is doing. Slowly, this turns an already long method/function of say 500 lines into an even longer method/function of 800 lines. Imagine the pain of going through huge amount of lines before you can actually start working on a small portion of it!. And imagine doing it every time for every method and every class you encounter!
• #6: Writing a comment in your code is like spraying a deodorant on your body before going to work on a day you have not taken a bath! You are well aware that you are stinking, but instead of taking an effort to take a bath, you decide to take a shortcut and cover your body with some really nice artificial fragrances. Luckily, for us it works, since sooner or later we will take a bath. But when it comes to code, imagine walking around a person who has rather than taking a bath, resorted to using a deodorant for his entire lifetime! Because this is what ultimately happens to your code! The comments never get removed and remain throughout the lifecycle of you software! Adding useless lines to your software that you can any day do without is the ugliest possible smell!
• #7: Why to write comments when you can name your functions and variables meaningfully! There are few hard and fast rules for this: Whenever you feel the need to write a comment in your code, it is an indication that there is a smell lurking around the corner. The best solution for this is to extract the piece of code (that you feel the need to write comment for) into a method and rename the method with the comment you wanted to write for it! If you feel the need to write a comment against a variable or for an already extracted method, consider renaming them so that the names themselves depict their purpose. If however, it is not possible to rename a method as it is doing more than 1 task, congratulations! you have many other code smells in your method! (don’t worry, you will be equipped with proper ways to identify and handle them by the end of this course)
• #9: Imagine yourself traveling on a long stretch of a highway trying to find out the route to your destination. And after a long time, you encounter this sign! How would you feel? Frustrated is just an understatement. This is exactly what you are doing to yourself and others when you are not writing an INTENTION REVEALING code. Now, what is an intention revealing code? Simply put, the code you write should be a direct reflection of your thought process involved in writing that code. Anyone reading the code should at first glance get a gist of: What the code is doing How it is structured Why it is written in such a way What feature it is contributing. i.e. what business scenario/user story it is answering And to your surprise it isn’t difficult at all! In fact it is much easier to write an intention revealing code than the traditional way of solving a software development problem! Follow along, and you’ll know what I am talking about!
• #10: The first step to writing an intention revealing code is to give meaningful names to your code constructs. a.k.a. variables, parameters, methods and classes. And believe me, it is the most difficult part of writing code! And also the most important one! The names you give to your constructs can single handedly decide whether you can solve your problem effectively or not! A common mentality of solving a software development problem is to first decide a data structure that you can use and then write logic on top of it defining its behavior. This is exactly what is wrong with your code! How do you think we invented wheel? Let me give you two possibilities: Someone came up with an idea of “a thing that can be easily dragged on road”. He picked up a piece of rock, tried chopping it and failed. He picked up wood, started chopping it and then moving it and chopping it again until the surface became circular, easier to move. He thought he could work with wood, imagined a circular design. Picked it, chopped it and voila! A new invention!! If you answer is 2, you can skip the slide. But if it is 1, congratulations you decoded the secret of every invention in human history! You’ll notice a common pattern in every scientific invention and discovery there is (baring few exceptions). Think of a behavior -> experiment -> implement -> give it a fancy name! Why should your code be any different!? A true object oriented design should start with defining behaviors first and then the logic and then an appropriate data structures that can be used to implement it. Not the other way around that most developers do! So if you want to implement a an object that moves on road, don’t straight away create a “Class” named “Car” and then the functions it performs. Instead think of a behavior you would want this object to perform: say “it moves forward”. Create a behavior say moveForward(), and trace back all the way to creating a “Class” implementing this behavior. It takes time to get used to this way of thinking, but once you do, you’ll realize the true power of object oriented programming!! And what is the important step in proceeding this way? Defining the behavior. i.e. moveForward(). The name sets the context to your problem and narrows down your brain to focus entirely on implementing this behavior. If you had rather given it a less telling name say move(), you’ll notice that your brain instantly floods you with all the possible ways of moving a car and how quickly this divides your focus! A mere name can determine which direction you move towards for a solution. What do you think is a better direction to go towards – moveForward() or move()? Do you now realize the importance of a good name?
• #11: This is the second most common code smell. And also one of the strongest! There are two kinds of duplication. 1. Blatant – easy to spot. 2. Subtle – Not easy to spot. Lets talk about the easier one first. There is an inherent tendency of a novice programmer to copy paste a piece of code that is performing same function, because apparently “It saves time”. What he fails to understand is the notion of saving time is very short lived. It NEVER WORKS IN A LONGER RUN. Reason? Imagine a 40 line code that is being copy pasted at 3 different places. Your new task is to write some code in two of these three places. Initially, you go through the code inside these classes to understand its functionality. Now this 40 line code happens to be surrounded by different code in the two classes (which is a very common scenario). You are potentially going through the same 40 lines twice before realizing its similarity. It like halfway through the novel, there is a chapter that is exact duplicate of the 2nd chapter, and before you realize the similarity, you have already spent half an hour reading it! Now just imagine this happens to you for every novel you pick! You might be lucky once or twice, and spot the similarity fairly quickly, but if this scenario occurs multiple times in your code, at some point you are bound to miss this and waste your precious time. This point is even more important than the previous one. Suppose in your software you have written a code to join two string using a delimiter say “,” (comma). And this functionality is used at multiple places, so you decide to simply copy paste the code at all these places. Suddenly, the client wants the strings to be joined with a “;” (semicolon). Image the pain of going through your entire software and find out all these places to make a change. Even worse is the situation where you miss out at one place and code goes into production, and unluckily for you, the client happens to use the software exactly at that particular scenario! You loose your client’s trust, and more than that, be ready to face you manager!
• #12: There is a very simple rule to avoid all this trouble. And that rule is: Never CHIPKOFY (Copy). REUSE!
• #13: The second type of duplication is difficult to spot and very subtle. That is why it is called subtle duplication. The codes might not be an exact replica of each other, but they are apparently performing the same functionality, with very slight change in the behavior. Switch statements, conditional loops with long codes inside each of the cases is the prime example of where this duplication occurs. In almost all the scenarios, there will be a common piece of code in all the different cases, followed by a slightly different code which makes these cases different. At first it doesn’t appear much of a duplication, but try changing the code in one of the cases. If you are forced to change code in other cases as well, there is a duplication!
• #14: There are various ways to remove duplication from your code. In fact blatant duplication is very easy to remove! All you have to do is to extract repeating code into a method and call this method at different places. (Others are written in the slide itself). Now, for subtle duplication, follow some procedures (written in the slide) to make the codes blatantly same. Then follow the same process as blatant duplication.
• #15: What is the purpose of creating an object in our software? Objects offer behaviors unique to them, which can be used/reused to solve a part of your problem. They are specialists performing certain tasks which your software cannot perform on its own. We hire people everyday to carry out tasks for us that we cannot do ourselves. A plumber can repair your water pipes, a cobbler your shoes. IT companies hire employees specialized in carrying out IT tasks. Now, imagine a person whose sole task is to take your precious items, keep them safe for a period of time, and when asked return them back. Isn’t this person dumb? Why do we need him at all? We can very well have lockers! Classes containing only fields and offering getter and setters to those fields are like this dumb human. They SHOULD NOT BE CALLED OBJECTS! Those are entities like lockers. In object oriented programming, objects have behaviors, and the behaviors are meaningful. People often fail to realize the true meaning of object oriented programming when they create classes/objects to hold data. Each object should have an associated behavior with it, and more importantly those behaviors should be useful. Data classes in your code are fundamental abusers of object oriented programming.
• #16: In maximum cases these data classes are used to HOLD data, which is later used in some function of another class. This couples your class carrying out the function, with the class holding the data. Now suppose if someone decides to change the data type of the field in the data class, you will have to modify the code at all those places where this field is being used. It causes a ripple effect across you project forcing you to make huge changes to your code base (and some of those places might even get missed!) The object oriented programming defines a fundamental principal describing the nature of the objects inside your code. It says: “TELL. DON’T ASK!” You should tell your objects to carry out tasks for you rather than asking an object for data and acting on that data. Object oriented programming brings behavior closer to data. Move behavior into an object to go with the data. Getters and Setters in your code stink. AVOID THEM AT ALL COSTS! Don’t make your classes dumb.
• #17: Not paying your house rent? Be ready to be thrown out of your house. Is there point in keeping someone/something that doesn’t pay of himself/itself. Why to add extra classes in your code just in the name of object oriented programming? Each added class brings with it, extra cost of maintenance and increases the complexity of the project. A Class should only be added to your code if it is doing some useful work. i.e. if its existence is justified. REMEMBER THIS RULE: Laziness is contagious! If a Class doesn’t justify its existence, throw it out of your code! DELETE IT! It is a Lazy class!
• #19: (Explained in the slide)
• #20: Keep out your food for long, and it gets rotten. Keep items in your room you no longer use, and it clutters your room. What happens if you don’t empty your garbage cans often? It starts stinking. And slowly the whole place around starts stinking. DO NOT GET ATTACHED TO YOUR CODE. Keep sticking to your past and you will never see the future. Keep you legs in two boats and you are bound to drown. SOLUTION: Ruthlessly delete code that isn't being used. No longer need a method? Delete it. No longer need a class? Delete it. No longer need the 4 lines of logic you took 4 days to implement? DELETE IT! Trust your brain to produce the same piece of magic again! It is a habit hard to get. It is really difficult to get rid of the code that came out of our beautiful minds. It will be difficult initially and you might have to push yourself and possibly shed some tears too! If it gets too heavy, tell the person sitting next to you to press the delete button. After some initial shocks, you will notice it gets easier with time. And as is written in every good book on spirituality, get rid of the materialistic attachments in the world, and lead a carefree life ever after! What if I need that code again? -What if we are attacked by electromagnetic radiation sucking Kaijus which renders every piece of our technology useless? Moreover, that is why SCM tools are in existence. To keep track of your code changes and revert in case you need to!
• #21: How many times have you added extra functionality to your class thinking it might be useful in future? And how many times have they actually been useful? No one knows what the future holds. We can simply not predict whether something will be useful in the future or not. Then why to unnecessarily waste time thinking about it and loading yourself with all the extra information and efforts required to maintain it? So unless, we enter the era of time machines, hold your thoughts to the present and code for what is required today, RIGHT NOW! DONOT CODE FOR FUTURE. LET YOUR FUTURE SELF HANDLE IT.
• #22: (Mentioned under dead code and lazy class) if you find something that is not useful, DELETE IT IMMEDIATELY!