Article Preview

COLUMN

Usable Code

Make code usable before you worry about re-use

Issue: 12.4 (July/August 2014)
Author: Seth Verrinder
Author Bio: Seth is a consultant who uses Xojo every day in his job at BKeeney Software, Inc.
Article Description: No description available.
Article Length (in bytes): 4,236
Starting Page Number: 58
Article Number: 12411
Related Link(s): None

Excerpt of article text...

Anyone who has worked for awhile as a programmer probably has a collection of code that they can draw on for new projects, but most of the code we write will only be used once. Nevertheless, there's a strong temptation to make code "re-usable" by trying to anticipate features that might be needed later. I think a better alternative is to embrace the fact that most code won't be re-used and focus on making code that does only what's needed now.

My Dad was a cabinet maker for many years before he retired. He built a workbench for his shop when I was about five years old and he still has it and uses it regularly. But, over the years, he's built hundreds or maybe thousands of jigs that he only used for one project.

A jig is a tool that's built for a particular job. For example, if you're building a run of similar cabinets, they might all have a piece that needs holes drilled in the same location. You could measure where the holes go on each piece or you could take a piece of scrap wood that's long enough and drill holes in that and then use that as a guide by placing it over the other pieces and drilling through the existing holes. That way, you've created a tool that you can use to make your job easier. But you don't re-use that tool for another job because it was specific to the requirements at hand.

I've seen a lot of developers (including myself at times) spend a great deal of time thinking about making code re-usable by adding features just in case they might be needed later. This leads to complex code and, in my experience, it rarely leads to actual re-use. In the worst case, we spend so much time on a piece of code or make it so complex that it never even gets successfully used let alone re-used.

Now I think it's better to focus on making code simple. In other words, make each piece of your program do as little as possible. If you focus on solving the problem at hand, you can spot patterns that come up again and again and then think about making something that can be re-used.

One example from our consulting work at BKeeney Software is active record. For years we did ad-hoc SQL code. We worked directly with the Database and RecordSet objects and constructed SQL strings as needed. That worked but we also began to organize our code around having a class for each table and properties for each of the fields of the class. Lot's of people have come up with this basic idea and it has a name: active record. At first, we built each active record class manually for each project, but after awhile it became obvious that most of the code in these classes was the same regardless of the project so there was an opportunity to make something that we could re-use.

...End of Excerpt. Please purchase the magazine to read the full article.