Free Association

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.

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.

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.

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.

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.

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.”

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.

I’ve been listening the Ruby Rogues podcast on programming language fundamentals.

One of the topics under discussion is languages appropriate for learning programming.

But that really depends on why one wants or needs to learn programming.

And there is a difference between learning to program to “get stuff done,” and really understanding what programming is all about.

Most people just need to get stuff done.

“Tradecraft” carries a connotation of high-stakes skullduggery, usually by semi-psychopathic agents of various governments, usually up to no damn good at all.

But what a great word, tradecraft.

In programming, tradecraft could be used to refer to all those accessory necessities, in particular, mastery of:

1. Your editing environment.
2. Your build system.
3. Your version control system.
4. The APIs and language features allowing you to trade in your craft.

All these tools are irrelevant to Computer Science.

Mastery of all is critical to mastering programming tradecraft.

Initially, it doesn’t really matter which set of tools are learned, so long as mastery is pursued. It’s the mindset that matters most.

Programmers who don’t write test-first code typically don’t write any test code at all.

The usual reason is that testing is hard and it takes too much time.

It’s true: writing software test code does take time, and writing test first code seemingly takes even more time.

But here’s the thing: everyone tests their code, if by no other technique than using visual feedback.

Visual feedback is manually operating the software and watching it with human eyeballs to “see” that it works correctly.

Typically this follows a code-compile-rewrite cycle. In the browser, it’s code-reload-rewrite.

It’s horribly time consuming.

Test first simply formalized this cycle.

Here’s the thing: just as it’s ridiculous to assume that the code will be written correctly on the first pass, its just as ridiculous to assume that tests supporting TDD will magically appear as the correct tests on the first pass.

Getting the tests right requires iterating the tests as the code is iterated.

The difference being that once the code does what it’s supposed to do, the test is in place.

Think of the tests in test-first as tools to help speed up learning about the problem.

When these tests take time, it means the problem is not well-understood.