Monthly Archives: June 2008

The Three Most Important Tools of a Software Developer

What are the most important tools of a software developer? In my view, the keyboard, a programmer’s editor and a scripting language are the top candidates. Compared to fancy design tools they might look mundane – but only at first sight: combined and mastered, they have the potential for making a developer an order of magnitude more efficient.

KEYBOARD

Let’s face it: as a software developer, you spend most of your time writing. Not just code but also test scripts, documentation and email. Hence, the keyboard is your most important basic tool, just like the saw is the most important basic tool of a carpenter.

It is a sad fact that many programmers don’t master touch typing and instead use the “Hunt and Peck” approach: they awkwardly enter text through slow and error-prone two-fingered typing.

The main problem with two-fingered typing is that since it is so cumbersome and slow, developers tend to avoid writing: they won’t write the Perl prototype of an application that would be so useful for the next trade fair and they certainly won’t write comprehensive documentation. Today, a large part of the communication in software projects happens through email, especially if the team is distributed over the globe – what a pity if you cannot type efficiently!

If you cannot touch-type as a programmer, you simply have to learn it. Now.

Fortunately, it’s rather easy. Within a couple of weeks you can achieve marvelous results by just practicing 20 minutes a day. There are countless programs for self-study out there, many of which are free, like KDE’s KTouch. Just do a search on your favorite search engine for “touch typing”. There are even games, like typespeed that you can use to improve your typing skills. Try it out, it’s great fun! However, it is important that you finish a systematic course first; that is, you know the positions of the basic keys blindfolded.

Once you are sufficiently proficient with the basic keys, you should tackle the remaining special keys as well, since they are quite important for software developers: punctuation marks, the ‘at’ sign, braces and brackets. Don’t stop until you know your keyboard inside out. If you catch yourself peeking at the keyboard too often, consider buying a keyboard with blank keys, like DAS Keyboard: a piano player doesn’t need letters on her keyboard and neither do you.

PROGRAMMER’S EDITOR

For years I had used various editors and IDEs for my daily work: for Java development, I used Eclipse, for C++ development Visual Studio, for batch file and test development as well as log file viewing and editing UltraEdit and TextPad; I used Outlook and Lotus Notes for composing emails and usually Microsoft Word for any other kind of documentation. Even though I read the Pragmatic Programmer’s advise “Use a single editor well”, I didn’t know how to live by it – until a colleague gave me a nice tour of the VIM editor about three years ago.

Ever since that day, my developer life has changed profoundly. Now, I use VIM for at least 90% of my writings. I even use it for composing emails, provided I expect my email to be longer than three lines of text. It’s just sooo cool! Now more do I use IDEs for building my projects; instead, I build from withing VIM by invoking a command-line build script; VIM’s “quickfix” feature lets me easily navigate between compiler warnings and errors. For me, the only legitimate use of an IDE is when doing source-level debugging; for changing the code and compiling I switch back to VIM.

I’m not trying to convince you to to learn VIM, since it is a large investment. It took me a couple of month to get some proficiency and even after three years, I’m still learning. But what a worthwhile investment it is for me!

Whatever editor you chose as your single editor, make sure you know it inside-out. Always ask “is there a smarter, more efficient way to accomplish what I want?” and check with the documentation. For instance, you should know how to program it, know how to create abbreviations and shortcuts, know how to record macros. Find out how to run external tools (like executing makefiles or checking out code from version control). Most importantly, learn all the hotkeys and key combinations for tasks that occur frequently, like deleting the word under the cursor (in VIM type ‘daw’) or indent the current paragraph (in VIM type ‘>ip’).

A programmer’s editor corresponds to a carpenter’s workbench: It serves as an integration platform for all your work.

SCRIPTING LANGUAGE

Even a craftsman sometimes needs power-tools to save time and get mundane and repetitive jobs done; so does the programmer and that’s where scripting languages excel.

By scripting languages I mean dynamic languages like Perl, Python or Ruby that don’t use static type checking like traditional languages such as C and Java do. Scripting languages are highly expressive and have constructs that let you achieve miracles in just a few lines of code. As an example, this Perl code

executes “my_prog.exe”, captures its output and counts the total number of error messages. If you are like me and think that this is still too long, here is the one-line version:

Try this in a traditional programming language of your choice and compare the total number of characters typed – expect that it will be 10 to 20 times as as many.

Most of the time, you will use scripting languages for automation and text processing; however, you can also use it to sketch and smear in order to develop prototypes that you might later recode in a traditional programming language.

A mastered scripting language is a great time-saver: It enables you to write lots of little utilities that make your and your colleagues life easier.

CONCLUSION

The combined power of touch-typing, a programmer’s editor and a scripting language makes a software developer much more productive in two respects: first, it ensures that jobs get done in little time and second, it encourages programmers to try out ideas. The latter is the basis for long-term developer motivation and outstanding performance.

How to Statically Initialize Arrays with Arbitrary Values

[Warning: Low-level C stuff ahead!]

Imagine a situation where you want to statically initialize an array with values different to 0:

This approach works, at least until someday you want to increase the array size to, say, 200. In this case, you have to add 192 times “42, ” to the initializer list. What a dread!

Everything would be easy, if you wanted to zero-initialize the array:

With zero-initialization, all you have to do is specify the value of the first element – all of the remaining elements will automatically be set to zero.

But sometimes you need a value different to 0 and you don’t want an additional call to “memset()” at run-time. Or you cannot use “memset()” because your array is stored in a read-only ROM segment and you cannot change the array’s values dynamically.

Basically, what you want is this:

Then, you would only have to make a single change to alter the size of the array (or the initialization value).

Alas, it turns out that it is impossible to define a macro that does the job we expect from “STATIC_INIT”. Think about it for a while. How would you solve this problem?

Sometimes, it is possible to replace a call to an impossible macro with the inclusion of a header file; I call this technique the “Replace macro call with file inclusion” trick:

The two defines represent the macro parameters and the inclusion of the header file represents the actual macro call.

You probably wonder what the contents of “static_init.h” are, but it’s instructive to spend some time on this problem yourself. Afterwards, you can have a look at my solution.

Note that this approach is not limited to single values – you can also use it for more complex initializations. For instance, if you need an alternating sequence of ’42’ and ’13’ you would do this:

I’ve also used the “Replace macro call with file inclusion” trick to encapsulate #pragmas and other compiler-specific features. Consider the case where you are working on a multi-platform project that uses different compilers. Consider further that you have a piece of code that generates compiler warnings and you want to locally turn compiler warnings off:

Now the problem with this approach is that #pragmas are compiler-dependent, which means that you will end up with something like this:

Not only does this litter the code – it is also a maintenance nightmare.

Usually, the solution is to encapsulate compiler specific features in #defines; alas this obvious strategy doesn’t work for #pragmas:

So it is time to roll out our trick once again:

Where, for instance, “warnings_off” looks like this:

You probably won’t need this trick very often, but when you do, it is good to know that it’s there.