Software Craftsmanship - Code Smells - Bloaters

Editor's Notes

• #2: This presentation is continuation to “Software Craftsmanship – Code Smells_1_Dispensables”. Here we will cover the second category of code smells – “Bloaters”.
• #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 second category here: Bloaters
• #4: What happens when you eat a lot at once? You feel bloated. This is because you fill your stomach with more than what it requires and it pays you back with tight abdominal pain. Similarly filling your software with huge chunks of code can bloat your software. Such a software becomes hard to work with as it is difficult for the programmer to digest such huge code at once. All such smells that make your code bloated fall under the category – bloaters. Lets see each of these in detail!
• #5: Mentally it is easier to add a line of code to your method than to create a new method. “Just 2 lines of code…surely I can fit it into this method”. This is similar to going out to a food street while on diet, and consuming “just one bite” at each of the stalls. Collectively the bites will break your diet! The lines of code keep getting added to the method, feature after feature until the method becomes an oversized beast. And then suddenly you realize it becomes difficult to understand and you end up wasting huge amount of time in either understanding it or breaking it down in order to reduce the complexity. Even worse, you leave the project and the other programmers have to deal with your mess! (non maintainable code) All of this could have been avoided with a little effort of creating a new method altogether (remember giving it a good name)!
• #6: To reduce the length of a method body, use Extract Method. If local variables and parameters interfere with extracting a method, use Replace Temp with Query, Introduce Parameter Object or Preserve Whole Object. If none of the previous recipes help, try moving the entire method to a separate object via Replace Method with Method Object. Conditional operators and loops are a good clue that code can be moved to a separate method. For conditionals, use Decompose Conditional. If loops are in the way, try Extract Method.
• #7: This is similar to long method but a little more difficult to identify. For a programmer, it is mentally easy to add few lines of code in the same class rather than creating a new one. Overtime, it leads to your class acting as a GOD object. What is a GOD Object? – An object that tries to do a lot of tasks at once. Such an object acts like a god in the realm of your software. Any and every task goes through this object before getting executed. Think of a Swiss knife with more than 100 tools. How easy it is to work with the knife? Yes, you have an all in one tool, but what’s the use of it if you cannot keep it in your pocket! Better to carry a toolkit instead right? Or more importantly, is it of any use if you can’t figure out the right tool for your job in short time? Toolkit would provide a much better solution right? The only thing the knife remains good for is to boast it in front of your friends. Large classes become difficult to handle and work with over time. It becomes a headache to maintain these and they are also repulsive to change.
• #8: Don’t let your class be a “Jack of all trades”, instead make it a master of just one! A class should always be responsible for one and only one function alone. Split your class into various other classes so that each of the newly created class handle a unique functionality. Treatment Extract Class if part of the behavior of the large class can be spun off into a separate component. Extract Subclass if part of the behavior of the large class can be implemented in different ways or is used in rare cases. Extract Interface if it is necessary to have a list of the operations and behaviors that the client can use.
• #9: This smell occurs due to programmer’s inability to think in terms of objects. Procedural programming involves using primitive types (such and int, char, float etc.) to represent complex data like Date, Address etc. When it comes to procedural languages like C, the programmer has no choice but to use this due to language limitations. The problem comes when the same mindset is carried forward to an object oriented language. Object oriented programming as the name suggests is writing code thinking in terms of objects. Using primitive types in object oriented languages is like rubbing two stones to generate fire when you have a matchstick in your pocket! Humans have come a long way from the stone age and programmers need to step out of it too! What’s wrong with using primitives? When primitives are used to simulate types such as “Date” for e.g., all the code that works on this variable tends to accumulate in the same class itself. This results in the current class handling all the functions relating to this variable type, and thus handling additional responsibilities apart from its current responsibilities. Most often than not, this also results into Large Class smell we just discussed. As an example, a Customer class containing code that deals with printing the DOB of the customer in a particular format based on the location of the customer. Should customer know about this logic?
• #10: GET RID OF THE PRIMITVE MINDSET! Treatment If you have a large variety of primitive fields, it may be possible to logically group some of them into their own class. And then, move the behavior associated with this data into the class too. For this task, use Replace Data Value with Object. If the values of primitive fields are used in method parameters, go with Introduce Parameter Object or Preserve Whole Object When complicated data is coded in variables, use Replace Type Code with Class, Replace Type Code with Subclasses or Replace Type Code with State/Strategy If there are arrays among the variables, use Replace Array with Object 
• #11: This is another smell that finds its root in the procedural mindset of writing code. Some reasons of having long parameter lists for a method can be: Byproduct of reducing method size - There is a code that implements a complicated algorithm and works on lots of data items. This piece of code becomes huge and you decide to extract it into a method. Now, the algorithm inside your method requires these data items. You have two options – 1. Use global variables 2. Pass these as parameters. First choice is a disaster in so many ways – as any code inside your class can access and modify these variables. So you choose the safer second route  Thus, along with the method goes your long list of data items as parameters. Now every time you have to use this method, you have to take care of all these parameters and pass them perfectly to the method so that algorithm works for you. Wouldn’t it be a headache if this algorithm is used frequently in your code? Byproduct of reducing class dependencies - For example, the code for creating some objects required by a method is moved from the method to the code calling the method. The objects are thus created in this separate caller class method and then passed into the called class method as parameters. The called class no longer needs to know the relationships between objects and dependency is reduced. But as a result, method becomes home for long list of parameters.
• #12: Did you ever wonder- Why is the algorithm inside the method using so many parameters in the first place? Are there any parameters that are closely related and be grouped into a separate object? You can then pass this object instead and reduce your parameter count? As a side effect, a part of you algorithm acting on these related items might very well be moved to this new object and reduce your algorithm complexity! Something that was not possible with procedural programming but you missed the trick due to your inability of crossing over to object oriented mindset! Treatment Check what values are passed to parameters. If some of the arguments are just results of method calls of another object, use Replace Parameter with Method Call Instead of passing a group of data received from another object as parameters, pass the object itself to the method, by using Preserve Whole Object If there are several related data elements, sometimes you can merge them into a single parameter object via Introduce Parameter Object Payoff More readable, shorter code.
• #13: Do you have in your codebase some data items that always appear together no matter where the code is present? They might be present together as class variables in various classes or might be passed together as parameters in various methods. All these data items are collectively called as data clumps. These bulk your code unnecessarily at all the places they are present. These data items are like flock of birds, always going together and refusing to fly without the other! Try deleting one of the data items. If the other items make no sense to you and you have to make changes to the code so that it makes sense, it is a big indication that a clump is present in your code. How do these clumps affect the code? (Read the consequences written in the slide)
• #14: Remember this - “Birds of a feather flock together”. Let these birds fly in a flock! Put them into their own separate object. Use this object instead of using the birds one by one. Then, move the code acting on this flock inside the object handling the flock! You’ll notice an instant reduction in code duplication! A NICE SIDE EFFECT  Treatment If repeating data comprises the fields of a class, use Extract Class to move the fields to their own class. If the same data clumps are passed in the parameters of methods, use Introduce Parameter Object to set them off as a class. If some of the data is passed to other methods, think about passing the entire data object to the method instead of just individual fields. Preserve Whole Object will help with this. Payoff Improves understanding and organization of code. Operations on particular data are now gathered in a single place, instead of haphazardly throughout the code. Reduces code size.