Skip to content
February 13, 2011 / marrowboy

Understand your code better by flowe-ing

One of this week’s evening projects was a quite enjoyable foray into Java parsers and code quality. I decided to write a little app to show me how I am (ab)using flow control.

The idea is to anonymise code, strip out all meaningful identifiers and functionality and show what’s left.


Flowe turns this kind of thing:

public class LovelyClass {
  public String getLongestString(List strings) {
    String longestString = "";
    for (String thisString : strings){
      if ( longestString.length() <= thisString.length() ){
        longestString = thisString;
    return longestString;

into this:


And provides a little summary:

Deepest nesting:   3 levels

By just considering the complexity of the code in an anonymous form, you free yourself from the tempting fallacy that “of course, this class has to be complicated, it does a complicated thing!”


When I demoed this at work, I made the assertion that less nesting is almost always going to result in cleaner code.

Ways to achieve shallower nesting include such refactorings as: using polymorphism instead of conditionals, extracting methods, or using method objects. Because these are refactorings, we are not attempting to change the functionality of the code, just hoping to make it easier to read and maintain. Ideally we will be able to internalise these kinds of changes, so that unnecessary complexity just looks wrong.

I guess I spend about 25% of my job telling the computer what to do, and 75% working out what other people were trying to tell the computer to do. NB Eagleson’s Law:

Any code of your own that you haven’t looked at for six or more months, might as well have been written by someone else.

Although in my case it’s more like 3 weeks!

How we flowe

A simple bit of bash scripting runs flowe over our whole codebase – the worst offending classes are shown prominently on our information radiator, and people notice them and fix them. We ought to do the same for cyclomatic complexity and other such things – find the problem classes quickly and show everyone where they are.


Recently I re-discovered the genius of Edsger Dijkstra, especially his famous and laconic quotes:

Elegance is not a dispensable luxury but a quality that decides between success and failure.


Simplicity is prerequisite for reliability.

His attitude was a great part of the inspiration for flowe. Hopefully, it will help you make your code simpler and more elegant => reliable and more successful. In honour of the man, I have added a purely speculative line to tell you what he would have thought of your code:

Dijkstra would be: dubious

Get flowe-ing

flowe is available for download as an executable jar or a self-executing bash script here:, or you can browse and check out the source here:

Postscript: “else if”

A surprise to me when I wrote flowe was the hidden complexity of else if:

if ( condition1 ){
} else if ( condition2 ) {
} else {

is parsed as


On reflection, though, this makes sense. It’s the same as:

if ( condition1 ){
} else {
    if ( condition2 ) {
    } else {

So the else if construct is just syntactic sugar, which tricks you into thinking that you’re not nesting your conditionals. Avoid. Use polymorphism, or a map, or something else. Or, if you’ve thought about it and it still makes sense, use else if, by all means.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: