Title: Professionalism in Programming #8

Perhaps the most obvious tool we use. Also perhaps the most fundamental tool - the programmer will spend most of their time using this piece of software. But that is why it should be very carefully chosen. The One True Source Editor is an age old debate which does not need stirring here, but you should use a source editor that you find comfortable and does what you require. Just because an editor is embedded in your visual IDE does not mean that it is the best editor for your purposes. On the other hand, you may find that having it integrated is an incredible boon. For source editing, I personally require at least the following from my source editor:

My requirements and choice of editor may not be yours.

e.g. vim, emacs, IDE editors, UltraEdit

The next most taken for granted tool. What else can convert our source code into machine code? Since we use this tool so pervasively, is not it important that we are sure how to use it? Do we really know all the options that it has? Do we understand what level of optimisation we require, and how that might change our code?^[4] It is true that in many places of work there is a specific buildmaster who ensures that tools in the build process are used correctly, but that is not an excuse to be unfamiliar with the compiler.

As another example, do you compile with all warnings switched on? There really is no excuse not to (perhaps only if you are maintaining legacy code that is already full of warnings). The warnings highlight potential errors and (when removed) give you extra confidence in your code. Also, is the compiler ISO standard [ISO] compliant by default? Does it have any non-standard extensions, and do you know what they are and how to avoid them?

Often we use a "cross compiler" when writing code for an embedded environment. This simply means that the target platform is different from the development one (after all, it is hard to run visual C++ on a washing machine).

The compiler is often considered a single part of a larger development tool chain, including the linker, assembler, debugger, profiler, simulator and other object-file manipulators.

e.g. gcc, Visual C++, Borland C++ builder

The availability of a good quality debugger and understanding how to use it can save hours of development time chasing surprising behaviour. It allows you to investigate paths of execution in your code, break into it, investigate variable values, set breakpoints and generally dissect your running program. It is an order of magnitude more sophisticated than using printf statements!

e.g. gdb, ddd, IDE debuggers

Used when code runs unacceptably slowly. The profiler times sections of running code and identifies potential bottlenecks. This tools is invaluable for optimisation and will prevent you from speeding up code that is only run once in a blue moon.

e.g. gprof, IDE profilers

Code validators come in two varieties, static and dynamic. The former can be run over code in a similar way to a compiler, to identify possible problem areas in the code. Lint is a good example of such a program - performing static checking for a series of common coding errors in C. A lot of this kind of functionality tends to be built into modern compilers, but there are still a number of very valuable tools available to complement this.

Dynamic validators modify the code as it is compiled, and then perform checking at run time. Memory allocation/bounds checkers are an example of this - ensuring that all dynamically allocated memory is freed appropriately, and that array accesses do not occur out of bounds. Again, the value of these types of tools cannot be stressed - they can save hours of legwork finding obscure bugs. They can be much more useful than a debugger in some situations.

e.g. Lint, Insure++, MemProf

The tools that comprise the build environment are more than just the compiler and linker. The kind of tools that are used are the "make" build tool, or the build portions of your IDE. They automate the compilation process. Many Unix open source projects use the autoconf/automake tools to simplify the build environment.

e.g. make, IDE build tools, automake/autoconf

A good shared database allowing colleagues to log, query, assign, reply to, and fix faults is essential to ensuring the quality of a product. Without something like this we cannot ensure that we have addressed every issue that has cropped up. Capturing and storing this information is useful when looking back over code at a later date.

e.g. Bugzilla, Matrix

Yes, these are tools! Reusing software components and finding libraries that do what we need prevents us from having to reinvent the wheel.

e.g. STL, Boost, Rogue Wave libraries

There is a whole field of tools to help you delve into and understand code, either presenting it in some graphical map, or enabling you to search/navigate through the code base. This can be especially useful on large code bases or when entering a project that is well established.

Good example of such tools are LXR, SNiFF+, the McCabe toolset and the venerable ctags.

We should also consider Unix source level tools such as diff, which allows us to compare differences in files (to see how it has been modified by someone else, for example) and grep for searching for information in files, plus locate/find to discover where in the build tree files are. (Naturally there are GUI equivalents on most platforms.)

We will not dwell on source control tools here, since we covered it in the previous column [Goodliffe7]. Management and work collaboration tools may be fundamental to a company is method of working allowing you to report and track work against the schedule, possibly encompassing fault tracking.

e.g. CVS et al. MS Project, Achievo

There are a number of tools that exist in order to generate code for us. Some of them, as I mentioned earlier, do not necessarily fill me with confidence. However, in the past I have written Perl scripts to generate code automatically. Having written the generator I trusted the code generated.

There are a number of other interesting code generators. For example, Yacc is a Unix LALR(1) parser generator. You use it to generate code to parse well formed input (by defining the input grammar). It spits out a C parser with hooks that you can write. Bison is a similar tool.

There is a class of code generation tools that help you design user interfaces, and then spit out the workhorse backend code. These are especially used for complex GUI toolkits like MFC. I am inclined to think that if the library needs a tool to do so much legwork, it implies the library is fundamentally broken in the first place.

Documentation is invaluable to code that is well engineered. Documentation needs to be read as well as written. Good online help systems (backed up by a quality bookshelf) are critical^[5]. The use of manuals, understanding how to web search well, as well as reading appropriate newsgroups and FAQs all contribute to your pool of available knowledge.

We also need to be able to write good documentation. We mentioned code documentation tools in a previous article [Goodliffe5]. We also need a good document processor (word processor or some such).

Appropriate testing is vital to producing reliable, high quality software. It is often neglected - and largely because it is "too much work", distracting attention away from the important task of writing code. This is one of the most dangerous threats to good software engineering. There are tools that help automate unit testing. This brings a host of advantages (we'll talk about this in a later column). Good testing is one of the tenets of the Extreme Programming movement.

As well as automated testing, tools can be available for the generation of test data or test cases, and for simulation of the target platform, perhaps with options to simulate particular error conditions (low memory, high load, etc).

e.g. Jtest

And naturally there are many more tools we use, for example OO analysis/design tools to help us compose object oriented systems, tools for evaluating code metrics and to investigate the quality of our code There are also scripting languages with which we can write other tools as needed (a little Unix shell goes a long way, but understanding the right language for the right job is an essential bit of background knowledge for the aspiring professional programmer).