Constructors should set state, nothing more

January 3, 2013 by

If a constructor has to do a lot of processing to set its initial state, that’s a code smell.

When a constructor is used for the main processing part of a class, such the code requires an instance of Foo to spend a lot of cycles computing Bar, that’s almost a sure indicator the design needs improvement. It may not need a lot of improvement, but it almost surely needs rethinking.

Constructors should only set state, really. If arguments
must be passed, those should be easy to instantiate themselves.

I’m not the only person who believes doing work in constructors is a flaw.

You can google “doing work in constructors” to find like thinking.

Really bad smell

Check this out:

Foo::Foo(Bar b) : b(b) {

 private_m = Baz::some_wackadoodle_preset_structure;
};

I recently had to find a way to test such a constructor, where the constructor depended on some static (global) value of another class, which was initialized elsewhere.

Very painful.

Filed Under: Coding

Design rule of thumb: 1 loop per method

October 19, 2012 by

Here’s a great little guideline for writing testable code: limit the number of loops in any function or method to 1 at each level of nesting.

Consider the following function with two “top level” loops:

def function():
    for ():
        ....
        ....
        ....
    for ():
        ....
        ....
        ....

Refactor 1

The body of a loop is often a great candidate for a refactoring. Do this instead:


def helper1():
    for():
        ...
        ...
        ...

def helper2():
    for():
        ...
        ...
        ...

def function():
    helper1()
    helper2()

Instead of sweating one nasty integration test for the function with two loops, you now have two unit tests (test_helper1, test_helper2) and two integration tests (test_function1, test_function2).

Refactor 2

def function1():
    for ():
        ...
        ...
        ...

def function2():
    for ():
        ...
        ...
        ...

function1()
function2()

Depending on what function1 and function2 accomplish, they might be amenable to unit testing as well.

Filed Under: Coding Tagged With: , , ,

The is pattern for queries

July 26, 2012 by

One way to partition functionality within classes is to separate command (mutate) actions from query (inspect) actions.

Query actions have a number of well-established naming conventions. Let’s examine the “is_whatever?” pattern.

Consider a car, a spider and word (Ruby syntax):

car.is_vehicle?       # true
spider.is_insect?     # false, spiders are arachnids
word.is_abbreviation? # 4. WTF!?

The convention is that any function or method prefixed with “is” queries for a boolean value. Returning anything other than true or false will induce cognitive dissonance in the reader.

The reader might well be you, next year.

Filed Under: Coding Tagged With: ,

Naming functions and methods

May 14, 2012 by

Function and method naming is not terribly difficult if the following two guidelines are observed:

Query functions return stuff. For example, new, create, get are all functions which ask for something in return.

Command functions change state. For example, set, adjust, compute.

Try very, very hard not to “mix and match”. Functions which both query and command are really hard to test, and worse, they are much harder to understand.

Think of it this way: testing a query function means testing only that the returned result is correct. Testing a command function means testing only the state of the object as a result of the command. If you have a function which commands and queries, you may find your function has weird interactions. Basically, your test code has to test the return, the state, and every possible interaction.

Plus, it’s just semantically confusing otherwise.

Update 2012/05/19: Command and query are analogous to “inspect” and “mutate” in the c++ world.

Filed Under: Coding Tagged With:

Good reason to learn Java, C/C++

April 26, 2012 by

C, C++ and Java may seem simply annoyances to programmers weened on scripting languages. But learning one or more of these languages is worthwhile, for many reasons.

One reason is this: Vast amounts of software engineering literature provide examples using these languages.

Currently, I’m reading “Working Effectively with Legacy Code” by Michael C. Feathers.

All the code in the book is (of course) C, C++ or Java. But the principles documented in the book are language independent.

The last example in the book, on extraction refactoring, is something I’ve been doing for years, and didn’t know there was a name for it. That’s pretty cool.

Filed Under: Coding Tagged With: ,

Learning to test-first

April 10, 2012 by

If you didn’t learn it that way, test-first isn’t the easiest way to program.

But it can be learned.

  1. Write the code you’re going to write anyway.
  2. Test your just-written code thoroughly.
  3. Keep your tests and throw away all your code.
  4. Now rewrite your code.

It takes extra time, but only the first time.

Given you’re writing test code anyway, test-first will pay you back the second or third time you write the code.

If you’re not writing test code, move along, nothing to see here.

Filed Under: Coding Tagged With:

Testing: clients will pay now or pay later

April 8, 2012 by

A former freelancer sends a message to a programming email list, explaining his full time job doesn’t give him enough time to update his former client’s website. And it’s on an obsolete and soon-to-be-unsupported version of the web application framework (which framework is irrelevant).

The main gotcha: he didn’t write any test code.

Most likely, the client was unable or unwilling to pay for the test code when the site was first created.

Most likely, the client will not be interested in paying for test code now.

The irony here is that had the developer originally written test code, he would have much more confidence updating the site.

The client pays regardless: either someone comes and cleans it up, or the client pays for a new web site. At this point, not writing test code increases developer time as the new developer reverse engineers the existing code. Might as well test.

Filed Under: Coding Tagged With: ,

Ruby vs. Python

April 2, 2012 by

After a couple of weeks of working with Python, some initial impressions.

1. The language is fine. Different than Ruby, no better, no worse.
2. The working environment needs a lot of work to match the ease of use provided by `rvm` and the `rubygems` system.

The current task is setting up the numerical toolchain, for which Python is celebrated.

The setup instructions for the numerical toolchain ask the user to set global variables for important tools such as gcc, fortran and the like, which is spectacularly inconvenient for people doing more than scientific python programming.

More later after I figure out how to firewall the python tools.

Update 2012/04/03: From StackOverflow, the Python community appears to be heavily RTFM. One of the questions I was looking up was how to find the number of items in a list. The obvious list.[size,length,count] didn’t work, nor did [length,size,count](list). Turns out it’s len(list). No comment.

Filed Under: Coding Tagged With: ,

The difference between test-driven and test-first coding

March 25, 2012 by

Test-driven development is often synonymous with test-first development, but perhaps that’s a little too restrictive. Everybody knows it’s not always possible to write test code first, thus the notion of a “spike.”

Here’s one way to do it:

  1. (Best) Test first when you can.
  2. (Almost as good) Test immediately after writing the code.
  3. (Still pretty good) Fix anything broken before pushing to remote.
  4. (Better than most) Push no uncovered code.

It’s worth noting that iterating into a spike by writing and continually rewriting tests results in a “covered spike.” It’s not test-first, but it’s hard to argue it’s not test-driven.

Taking test-first as an optimal strategy for development, we can redefine test-driven development as “push no uncovered code.”

Filed Under: Coding Tagged With: ,

What is a Code Kata, anyway?

March 23, 2012 by

A “code kata” is a sequence of steps covering every activity necessary to hardwire a path from one state to another.

In martial arts, a kata has a starting point and a stopping point, so too does a code kata.

A code kata starts from a position where everything is known, and proceeds along specific steps to a desired result.

Typically, a code kata is less about programming and more about framework and configuration.

The end result of an effective code kata reduces implementation time by 90%.

Here are a few code katas I’ve developed for building Ruby on Rails applications.

* Devise
* Email
* Cucumber BDD

Developing a kata is very time consuming. The payoff is that 90% reduction in effort.

Filed Under: Coding Tagged With:
«Older Posts