Code Change Complexity

March 24, 2014

Recently, I’ve been using algorithmic complexity as a metaphor for change complexity.

Usually, when people talk about complexity in code, they are talking about cyclomatic complexity in classes and methods, but the fact of the matter is that there are other forms of complexity that are worth noting - particularly the complexity of . . .

Ripeness for Refactoring

March 24, 2014

People don't refactor nearly enough in most projects. It’s easy to find large classes and methods, inscrutable logic and poor naming in most code bases. When we have that sort of situation it’s easy to just look the code and say “that needs refactoring.” The implication is that we should fix problems when we see them - if we can identify . . .

A Default Identity Value for Programming

December 19, 2013

Default values can make programming easier. On the other hand, they can confuse us a bit. In C and C++ default values are considerable work. We need to know when the language (or our abstractions) are providing them and when they aren't. In some languages, things are clearer - numerics are always initialized to a flavor of zero.

. . .

Making Map Operations Implicit in Programming

December 17, 2013

Every once in a while a couple of ideas come together. I was running a workshop on error handling the other day and over the course of it we started discussing the Maybe monad and Scala's Option type. I put this example from the Scala docs up on the screen:

val name: Option[String] = request getParameter "name"
val upper . . .

Private Languages in Code

December 10, 2013

There are many ways of writing incomprehensible code. Most of us have tried many, but every once in a while I see a new one.

About a year ago, I looked at a large method that set a series of boolean flags up at the top and referred to them about 300 lines further along in its body. It's easy to look at this and say that the root . . .

When A Method Can Do Nothing

November 19, 2013

Refactoring is full of choices. When I start to work on a large method I look at its overall structure and try to get a sense of how to break it down. Conditional statements are often problematic for me.

 if (...) {
...
}


When I have an if-statement like this I know that I have a choice. I can extract the if and its . . .