Robert Ames (.com!)

Run-on Programming

I was reading through some code at work today and it inspired me to propose a new vocabulary word for programmers. “Run-on Programming” It’s like a run-on sentence, but with functions.

    function doSomething()
    {
        doThis();
        doThat();
        doTheOther();
        imTired();
    }

    function imTired()
    {
        doMore()
        andMore()
        andEvenMore()
        soTired()
    }

    function soTired()
    {
        finish()
        things()
        up()
    }

…it’s like people know they should break things up into functions (so they do), but they don’t grasp the underlying concept of what functions are good for in the first place.

If you catch yourself doing this, you’d want to just leave things as a series of procedural steps instead of chaining state-modifying functions just for the sake of breaking things up.

    function doSomething()
    {
        doThis()
        doThat()
        doTheOther()
        doMore()
        andMore()
        andEvenMore()
        finish()
        things()
        up()
    }

Even more preferable would be to read about functional programming styles and how you can score the higher-level advantages of “functions” as opposed to being just places to put things.

First lesson: When you’re breaking functionality into pieces, make helper functions that don’t depend on global state (only on their parameters) and that do not modify global state (only return results).

    items = convert( get() )
    foreach items as item
    {
        result.push(
            merge(
                create(),
                item
            )
        );
    }

Looking at the above example, convert uses information returned by get, but could also use information from loadFromDB, parseEmail, etc… In addition, because convert has well-defined inputs and outputs, it is testable. merge similarly makes no assumptions about its two sources and is similarly testable.

08:40 CST | category / entries
permanent link | comments?