Visual Basic

Starting with Bases Loaded

Why Base Code?

How many times have you sat down to begin a new project and wondered exactly where to start? Do you begin by creating the screens you need, writing the low-level functions, or (as often seems to happen) do you just leap in somewhere in the middle? Then maybe somewhere down the line, you suddenly realize that you need to decide how to handle and report errors. This can leave you having to retrofit an error handling strategy into hundreds, if not thousands, of lines of code. With a properly designed set of base code, most of these decisions have already been made, and vital items-such as a coherent error handling strategy-are already implemented. All that remains is for you to plug in the forms and routines that are specific to your individual application.

Any serious application-regardless of size-will need to have some form of infrastructure. By infrastructure, I mean units of code that bind the application's functional units and provide general application support services. A classic example is the error handler whose job it is to maintain application state under erroneous conditions, and provide support services such as logging and tracing. Infrastructure functionality is essential to the application, but often the functionality is not included in any functional or design documentation. This can create problems: now the programmer has to write infrastructure code that has not been factored into the development time estimates. We estimate that using our own application template saves about a month of development time when creating an application from scratch. I'm sure most developers will agree that the majority of projects are developed under stressful time constraints, and an additional month of unplanned activity can mean less sleep! Multiply that by the number of applications your company develops during a year and you can start to see the cost- and time-saving potential of using base code templates.

Timescales are more often than not the major driving force behind an application. However, when the crunch comes, the timescale often succumbs to the more urgent need to iron out bugs and implement overlooked functionality. The problem with not having developed base code up front will manifest itself as a continual series of retrofit changes, each one becoming more difficult as the amount of code to integrate grows. In the reactive rush, standards slip and duplication occurs. How many occurrences of the bFileExists function can you find in one of your applications? The problem of duplication will always exist when working under these conditions because programmers on a project rarely have time to share information about functionality that they have added. As a programmer, you will probably assume a function you require does not exist and write it yourself. If that function does happen to exist already, there is a high probability that its code is different, and it might even have a different function name. The contract market is booming, and sometimes a particular programmer has worked with several programming standards from a variety of organizations. In high-pressure situations, the programmer is tempted to treat infrastructure routines as almost incidental. Instead of meticulously sticking to the organization's standards, the programmer might wish to code quickly, using whatever standard comes to mind. Comments will be scarce-if written at all. By this point in the development cycle, all the business can see is slipping deadlines. Code reviews-what are they? Congratulations, you now have most of the ingredients for creating the perfect maintenance nightmare!

By now it should be obvious that using base code has benefits. From a coding perspective, base code allows developers to concentrate on the functionality of the application-that is, the functionality that has been specified and cost-quoted. Most developers would much rather spend their time developing the application functionality because that's where the "clever" algorithms come into play. Writing this code is a real ego boost and many developers take pride in being able to write code that stretches their abilities to the limit. This code is far more likely to contain comments and follow the official coding standards. You can almost hear the programmer crying out for the "work of art" to be reviewed.

Base code encourages code reuse because the average programmer does not want to write bFileExists. Knowing that there is a base framework containing this "trainee programmer" type of code, programmers are more likely to actively seek out such a routine rather than write it themselves. However, you should remember that many programmers have limited patience. If you were writing a really cool routine that had to perform different actions based on the operating system, you might scan for a GetOSPlatform function in the base code. If such a function did exist, it would be vital that the programmer could find it-in a reasonable amount of time. Intuitively named modules might help here. Another major help is the function's interface. I will cover these topics in more detail later in the chapter.

An application's base code will often need to use specialized API calls, especially for the environmental-type functionality. One example is the Version API functions. In the old days, a badly defined or called API routine would simply cause a General Protection Fault. However, Microsoft got fed up with complaints about such faults-invariably caused by misuse-and built extra layers of validation into the API. Now you can get away with both wrongly declared and wrongly implemented API calls. In most cases the routine just doesn't work but the application is not as likely to crash. Using a good base code template allows complex functionality like this to be abstracted from the application. The developer need not understand how a function works, just that it does. A good base code template can allow developers new to Visual Basic to come to grips with applications more quickly than they otherwise would by concentrating on the business functionality rather than the infrastructure. There are many other reasons you might want to seriously consider using base code templates. Here are some more:

  • Using a base code template means that tried and tested, complex, low-level routines can be added to projects in the knowledge that they already work. Many of the routines in the TMS Application Template contain complex API calls, which, if the routines were written from scratch, would require extensive debugging and testing. When you are writing an application, the knowledge that some of the messier functions have already been written and debugged can be a great relief.
  • Starting from a set of base code imposes a set of coding and design standards on the developer right from the start. When an error handling strategy has already been implemented, it is usually much easier to go along with what's already there than to branch out in a different direction. Similarly, when developers become familiar with the naming conventions used throughout the base code, they will be more likely to fall into line with them than to ignore them.
  • Base code allows you to implement a consistent subclassing strategy. Subclassing is an area that I will be discussing in more detail shortly. For those not familiar with the term, subclassing is basically the concept of taking an existing Visual Basic function or object and replacing it with one of your own so that it is modified functionally.

I hope that by now you have been sold on the idea of base code templates. On all levels, from corporate to project management to development, base code templates are useful. The bottom line, I suppose, is that using some form of template will save you money, time, and effort.