Simpler Tests thanks to “Extract Method” Refactoring

by Lukas Atkinson

I'm currently refactoring a huge method into smaller parts. It is stock full of nested loops, maintains a complex state machine with more variables than I have fingers, and is the kind of code where I have to ask myself how I could ever think this would have been a good idea. So obviously, I'm splitting that function into smaller, independent chunks with the Extract Method refactoring technique. Since the control flow is now simplified, the code has also become easier to test – as long as I'm comfortable with testing private methods. Why?

The number of test cases needed for full path coverage corresponds directly to the McCabe complexity of the code under test. Since many simple functions often have lower total complexity than one convoluted function, the overall required testing effort is reduced. As this reduction can be substantial, there is a strong incentive to test the extracted methods directly, instead of testing only through the public interface.

read full post (7 min)

Reasonable Code

If it's impossible to follow, that code is bad.

by Lukas Atkinson

What is reasonable code? In an article on The Whiteboard, a fellow software developer under the pen name “Jimmy Hoffa” thinks about reasonability as a measure of code quality. He arrives at six exemplary properties of reasonable code:

  • small scope
  • short stacks
  • explicit data use
  • explicit data ownership
  • explicit outputs
  • dictating instead of deciding

He makes a good case for continuous self-​improvement and a focus on code quality in our development process. It is well worth the read, especially for beginning professionals. And not quite by chance, it seems to be a subtle advertisement for functional programming and static typing: anything else would have a hard time meeting his characteristics of reasonable code.

read external article (5 min)