Code Smells

Or: argh! Where do I start?! This is part of a series investigating code that looks suspicious ("code smells"), and exploring possible alternatives. Code Smells: Null Code Smells: Deeply Nested Code Code Smells: Iteration Code Smells: Mutation Code Smells: Multi-Responsibility Methods Code Smells: If Statements Code Smells: Too Many Problems For the middle articles of this series, we've been focusing on a single method, and demonstrating how to improve this method, one smell at a time.  While it has been… useful… that a single method has demonstrated so many smells, if yo

This is part of a series investigating code that looks suspicious ("code smells"), and exploring possible alternatives. Code Smells: Null Code Smells: Deeply Nested Code Code Smells: Iteration Code Smells: Mutation Code Smells: Multi-Responsibility Methods Code Smells: If Statements Code Smells: Too Many Problems The article in this series that has so far provoked the most responses was on iteration. Today, I'm talking about if statements (conditionals). I'm not intending to go after any sacred cows or anything – for loops and if statements are pretty much the first things w

This is part of a series investigating code that looks suspicious ("code smells"), and exploring possible alternatives. Code Smells: Null Code Smells: Deeply Nested Code Code Smells: Iteration Code Smells: Mutation Code Smells: Multi-Responsibility Methods Code Smells: If Statements Code Smells: Too Many Problems In the last article I introduced a large and complex method, validateQuery.  The focus of that article was how to simplify the method looking only at the "smell" of mutability, but there's actually one very simple change that can chop the method nearly in half.

This is part of a series investigating code that looks suspicious ("code smells"), and exploring possible alternatives. Code Smells: Null Code Smells: Deeply Nested Code Code Smells: Iteration Code Smells: Mutation Code Smells: Multi-Responsibility Methods Code Smells: If Statements Code Smells: Too Many Problems In the article about deeply nested code I wanted to change getMappedField to return an Optional value. The change to the method was fairly trivial, the change to the code that calls that method... well, that turned out to be another matter altogether. (more&hell

This is part of a series investigating code that looks suspicious ("code smells"), and exploring possible alternatives. Code Smells: Null Code Smells: Deeply Nested Code Code Smells: Iteration Code Smells: Mutation Code Smells: Multi-Responsibility Methods Code Smells: If Statements Code Smells: Too Many Problems Last time we looked at some suspicious nested code, and I suggested that the best way to deal with this was to move some of it into a different class to stop the original class having to understand the internals of how the data was stored. The Smell: Iteration

Or: I wants all your data, give it to me… my precious…. This is part of a series investigating code that looks suspicious ("code smells"), and exploring possible alternatives. Code Smells: Null Code Smells: Deeply Nested Code Code Smells: Iteration Code Smells: Mutation Code Smells: Multi-Responsibility Methods Code Smells: If Statements Code Smells: Too Many Problems Continuing the series of code smells and what do about them, in this post I examine some fairly innocent looking code that defies the obvious refactoring.  Although the code example itself is fairly trivial,

This is part of a series investigating code that looks suspicious ("code smells"), and exploring possible alternatives. Code Smells: Null Code Smells: Deeply Nested Code Code Smells: Iteration Code Smells: Mutation Code Smells: Multi-Responsibility Methods Code Smells: If Statements Code Smells: Too Many Problems During my research on refactoring I've seen a number of patterns (smells) crop up again and again. None of these are particularly new, and there are plenty of books, blogs and videos that cover smells and how to deal with them, but I wanted to demonstrate some speci