Author: Gianfranco Berardi

A colleague of mine was complaining about pair programming. He said one of the problems was that it restricted his coding creativity when he had to argue or discuss what he wants to do with someone else.

I was reminded of a forum post I made many years ago in which I similarly said something about creativity in code. Someone replied and said something to the effect of, “No, software development is engineering, not creativity.”

I have since thought about that response often, and it made an impression on me.

So I told my colleague that if you’re being creative while programming, it probably means you don’t know enough or have enough experience to know what to do.

An example I gave to him was some work we had done together in the past. We created a set of classes to handle filtering some data based on some criteria. We had come up with some very good work here. It was test-driven, very clean, and worked well. We spent about a week on it.

It was a creative solution.

But only because it wasn’t until months later that someone pointed out that what we had implemented was already provided by the 3rd party framework most of our software was based on.

Had we known that there was an existing solution, there would be no need for creativity. We would have simply solved the problem and moved on.

On the other hand, we’ve learned that incremental development results in better software. Rather than do the waterfall approach of big design up front, we implement a working piece of value, then build on it.

Often, the process of building the software is the way we learn how to build it. Coding, then, isn’t merely a matter of giving form to requirements, but a way of exploring the problem space. Write some test code, see what happens, and gain a more accurate understanding of what you’re making. Rinse, and repeat.

Software is malleable and allows such experimentation. The end result is a working program to run. We have created.

But can we call it creativity?

Many years ago, I was creating the best RPG ever! a walking demo of an RPG. I wanted the ability to talk to villagers and have conversations instead of merely receiving a single canned message.

I wrote a bunch of logic to load messages, identify if there were branches based on certain things being available such as a quest item, and even provided a way to choose options as replies. You could buy and sell things, which allowed you to change your inventory and your money supply. Inspired by Final Fantasy III‘s thief town, you could even lose money just by talking to certain characters.

I was very proud of the system I came up with and put together in QBasic. I came up with a very creative solution, I thought. It wasn’t until years later that I realized I basically reinvented what’s called a scripting engine.

Had I known about the scripting engine concept, I probably would have realized that it was exactly what I needed. Instead, I stumbled into it over many days of hacking together something that did more and more as I thought of it.

Then again, even if I know the concept, isn’t there some creativity in the specific implementation? Or am I mixing up the roles of the programmer and the game designer here?

If I write some code to calculate mortgage interest for a bank and realize that a side-effect of my effort is that it is easier to get data for some strategic analysis, that’s not programming creativity so much as business insight. Similarly, realizing that I could add another cool feature to the scripting engine is more about adding to my game design capability than about being creative with code. The code was just the way I expressed the creativity of game design, and so therefore incidental to it.

One of the things I believe is that being cute with programming means more headaches than it is worth. There’s a bug in your OS you can exploit to accomplish some data manipulation faster? Great, until it is patched. Best to stick with documented features and not trust that what happens to work today is what is right.

Similarly, writing “creative” code seems like a recipe for disaster. How clear can your code be if you’re being creative when you write it? You want to be creative? Experiment with code katas. Hack away for fun on a side project. Join the The International Obfuscated C Code Contest. But I don’t think “creative” code belongs in released production.

I think creativity in code is just another way of saying, “I’m guessing that this might work. Let’s see what happens.” It’s like throwing things into a fire and observing the results. It’s not creativity so much as experimentation.

When I learned about design patterns, entire concepts were made clearer to me, and my programming capability improved. I didn’t have to be as creative to write code to solve a problem or accomplish a task. If I’m ever trying to be creative while writing code, I think it says more about my lack of knowledge in the area than with the nature of programming.

What do you think? Is there creativity in programming?

(Photo: http://www.flickr.com/photos/chrisjrn/8058863952/ | CC BY-SA 2.0)

In 2008, I wrote Test-Driven Game Development, which was more about being reintroduced to Test-Driven Development (TDD) and asking if other game developers use it regularly.

Around the time, Noel Llopis had written a survey of C++ unit test frameworks, and eventually co-wrote UnitTest++ as none of the existing frameworks were sufficient for his needs.

I’ve used it ever since.

At my day job, I’ve been introduced to Google Test. It’s so much more full-featured, and paired with Google Mock, it means I don’t need to handroll my own mocks and fakes.

Since UnitTest++ isn’t actively maintained anymore, and Google Test does so much more, I’m switching my development to it.

I do my development on a Linux-based system. I use CMake to manage my builds which allows me to produce a game and port it to Windows easily.

It took me an hour to switch a project over to Google Test. Actually, it took mere minutes to change the code:

TEST_FIXTURE(ParticleFixture, ParticleInitializedWithPositionAndImpulse)
{
CHECK(particle.isAlive());
CHECK(initializedPosition == particle.position);
CHECK(impulse == particle.velocity);
CHECK_EQUAL(maxLifeTime, particle.lifeTime);
CHECK_EQUAL(maxLifeTime, particle.maxLifeTime);
}

turned into:

TEST_F(ParticleFixture, ParticleInitializedWithPositionAndImpulse)
{
EXPECT_TRUE(particle.isAlive());
EXPECT_TRUE(initializedPosition == particle.position);
EXPECT_TRUE(impulse == particle.velocity);
EXPECT_EQ(maxLifeTime, particle.lifeTime);
EXPECT_EQ(maxLifeTime, particle.maxLifeTime);
}

What took longer was figuring out how to add Google Test to my project’s structure.

With UnitTest++, I built it once and had a copy that all of my projects could leverage.

Google Test started out allowing you to “make install”, but citing C++’s
One-Definition Rule, the developers say:

we recommend to avoid installing pre-compiled Google Test libraries. Instead, each project should compile Google Test itself such that it can be sure that the same flags are used for both Google Test and the tests.

I spent quite a bit of time seeing if there was an example of how to do it, but build configurations are based on the needs of individual projects and I suppose it is hard to make such recommendations. So I had to figure out how to write the CMake file, and that’s always a painful process of figuring out what abstract implementation detail is provided by CMake to do the specific work you want.

So here’s my solution.

First, I added the gtest-1.7.0 directory to my project’s test directory. I suppose I could take steps to make this more generic and allow for upgrades without requiring me to change more than necessary, but it works, and it can be tweaked.

Second, I changed my CMakeLists.txt file.

INCLUDE_DIRECTORIES (${BUILD_ENV_LIB}/UnitTest++/src/ ${PROJECT_SOURCE_DIR}/source/game ${PROJECT_BINARY_DIR}/source/game ${PROJECT_SOURCE_DIR}/source/tests/Mocks)
ADD_EXECUTABLE (Test${GB_PROJECT_NAME}-bin ${TEST_SOURCES})
TARGET_LINK_LIBRARIES (Test${GB_PROJECT_NAME}-bin ${GB_PROJECT_NAME}-lib ${BUILD_ENV_LIB}/UnitTest++/libUnitTest++.a) # ${SDL_LIBRARY} ${SDLIMAGE_LIBRARY} ${SDLMIXER_LIBRARY} ${SDLTTF_LIBRARY})
# Run the test executable.
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/RunTest.sh ${PROJECT_BINARY_DIR})
EXECUTE_PROCESS(COMMAND chmod +x ${PROJECT_BINARY_DIR}/RunTest.sh)
ADD_CUSTOM_COMMAND(TARGET Test${GB_PROJECT_NAME}-bin POST_BUILD COMMAND ${PROJECT_BINARY_DIR}/RunTest.sh ARGS ${PROJECT_BINARY_DIR}/Test${GB_PROJECT_NAME}-bin VERBATIM)


became


ADD_SUBDIRECTORY (gtest-1.7.0)
enable_testing()
INCLUDE_DIRECTORIES (${gtest_SOURCE_DIR}/include ${gtest_SOURCE_DIR} ${PROJECT_SOURCE_DIR}/source/game ${PROJECT_BINARY_DIR}/source/game ${PROJECT_SOURCE_DIR}/source/tests/Mocks)
TARGET_LINK_LIBRARIES (Test${GB_PROJECT_NAME}-bin ${GB_PROJECT_NAME}-lib gtest gtest_main) # ${SDL_LIBRARY} ${SDLIMAGE_LIBRARY} ${SDLMIXER_LIBRARY} ${SDLTTF_LIBRARY})
ADD_TEST( Test${GB_PROJECT_NAME}-bin Test${GB_PROJECT_NAME}-bin )
ADD_CUSTOM_COMMAND(TARGET Test${GB_PROJECT_NAME}-bin POST_BUILD COMMAND ${PROJECT_BINARY_DIR}/Test${GB_PROJECT_NAME}-bin)


I used to have my own script run the tests because UnitTest++ didn’t do color-coding. I wanted to see red on failure and green on success. Binaries created using Google Test has red-green colors built-in so I could get rid of my RunTest.sh script.

I’ll be honest, though, I’m not sure what ADD_TEST() is providing. I kept seeing it recommended in the blog posts I could find out there, but as far as I can tell, no one says “I want to run my Google Test tests immediately after a build”.

Supposedly it adds a “test” target to your Makefile, but it seems to be broken. Hence, the ADD_CUSTOM_COMMAND() to actually run the command. I wish the official Google documents would say, “If you want to run your tests as part of the build instead of having to explicitly ask for it, do this.” Instead, I had to cobble together bits and pieces of information from a variety of sources.

So I hope this post helps you if you’re trying to integrate Google Test into your project. And if you see anything I’m doing that can be improved upon, please let me know. It seems project structure and CMake is a dark art to me, and I’m sure there is some workflow improvement I’m missing out on.