So for this weeks article I thought I would switch things up and try a different podcast. Instead of Coding Blocks I decided to go with Complete Developer, which was the first podcast group I had listened to when I first started listening to Computer Science podcasts. The first one I had listened to was called Code Smells part one, and I will actually be talking about the second part that I had listened to this past week. In the first part of the Code Smells podcast they talked all about what Code Smells were and how they correlated with class structures and architecture. Before we talk about what was talked about this time around, we should first redefine what Code Smells are. They are defined as Code Smells that are quick and easy to identify that may need to be refactored. They are high level signs that point to areas that you may need to take a closer look at in your code. This does not mean that you need to refactor, you just need to look at the code in more than one angle. There are a number of different Code Smells from general to paradigm to even language fracturing different smells. Today we will talk about different code smells related to the actual code itself with naming, unnecessary and bloated code. Naming conventions is important and keeping to that criteria is also important. You should name methods on what they do, not what they produce. Uninformative naming can cause code smells and this varies from person to person. Method names that do not describe what the method does is no good. Other developers should be able to read the methods and know what the method does. They also should know who wrote what code. To go along with this is inconsistent naming. This is naming that does not match throughout the code. They even mention a story about a co-worker who would change their code after an object would go through a method, which is very bad. Make things consistent can help you to automative things with your code, so pick a standard and stick with it. Another thing that can cause Code Smells are the “Do something ahead” which is when you have unnecessary or pointless code/ boostrapping code. Absence of these help for cleaner code. Anything that is not being used in the application, compilers remover anyway, so if you keep all of this unnecessary coding there will be Code Smells seen. Another problem is when requirements change and things get commented out. When you leave commented out code, branch it out instead, that way you can always go back to it but its not in your code and instead in your source control. The point of code smells is that they are quick easy ways to see deeper problems. Redundancy, more than one duplication, is when two classes, or two methods do the same thing, may not have the same code but do the same thing is another Code Smell. It happens when multiple developers are working on the same thing in a project and are unaware of each others efforts when solving that problem. So the wet code needs to be dried out, and by that don't repeat yourself. After that they go off on a tangent about comments and when they should and for the most part shouldn't be used. As always I really enjoyed the podcast. I am always happy to be able to find another podcast that is just as enjoyable to listen to as Coding Blocks. I think the way they split this up into two different podcast was also helpful so I wasn't getting a lot of information all at once. It's important to note the different kinds of Code Smells so when I am coding I can be aware of them and fix them before they get even smellier. Enjoyable and interesting as all of my other ones!
