Code Smells and Waste Management

- - posted in 10000 Hours, Flatiron School

Have you ever walked down the street and stared in wonder at the hussel and bussel of everyone in cars and taxis, on bikes, and on foot gets to where they need to go?

I’ve been making my way through Refactoring by Jay Fields, et al. They cover a laundry list of different ways code smells can inform how to refactor your code. A few which I will cover in the following posts include:

Duplicate Code: Number one in the stink parade is duplicated code. If you see the same code structure in more than one place, you can be sure that your program will be better if you find a way to unify them. The simplest duplicated code problem is when you have the same expression in two methods of the same class. Then all you have to do is Extract Method and invoke the code from both places.

Long Methods: The object programs that live best and longest are those with short methods. Programmers new to objects often feel that no computation ever takes place, that object programs are endless sequences of delegation. When you have lived with such a program for a few years, however, you learn just how valuable all those little methods are.

Large Classes: When a class is trying to do too much, it often shows up as too many instance variables. When a class has too many instance variables, duplicated code cannot be far behind.

Long Parameter Lists: In our early programming days we were taught to pass in as parameters everything needed by a routine. This was understandable because the alternative was global data, and global data is evil and usually painful. Objects change this situation because if you don’t have something you need, you can always ask another object to get it for you. Thus with objects you don’t pass in everything the method needs; instead you pass enough so that the method can get to everything it needs.