Good Code Form in Excel
- Modular Code
- Naming Conventions
- Nesting Code
- Commenting
- Benefits of Good Form
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Excel's integration development environment (IDE) has made it easier to develop powerful applications. With Excel's IDE, it is easy to quickly create applications to meet the functional needs of users in the organization, but it is in these rapid development environments that poor coding habits occur. Often with tight deadlines and in a user-friendly IDE, it is easy to forget good form because we often fool ourselves into believing that the code is fairly simple and requires little rigor.
However, applications grow, programmers move on, and old applications need to be maintained and expanded. We should approach all our applications with the belief that they will last a long time and be valued by users.
NOTE
On a personal note, I like this inflated sense of self-worth! Besides, if I am ever hit by a bus (I have a bus phobia), someone will need to easily take over my precious code. In reality, users often will ask for enhancements nine months later—when I have truly forgotten everything that I've done and now have to scramble to add this new functionality to my application. Thus, it is important to practice good programming discipline and write code with good form.
There are four main areas for good form, which are discussed in the following sections:
Modular code
Naming conventions
Nesting code
Commenting
Modular Code
The first good form in coding is creating modular code. This means breaking the program into more manageable submodules rather than creating one large behemoth program. Using a modular approach allows me to tackle the code incrementally, and I can then easily test my code and move on to the next challenge. With large code, however, it becomes more difficult to track down errors and to add functionality. Besides, before any project I break down the major functions of the application to build and they become the modules of my code. In essence, I am creating a roadmap of how I will build the application. The modules are almost like my to-do list for the project, and over time I will be able to reuse them as I build up a library of these modules (more on reusability later).
NOTE
For example, an application that the finance department may need will take and process credit applications, so I will create modules that will perform form validation, credit-worthiness, fraud screening, and so on. Later, I may find that the credit-worthiness may further break down into modules that calculate ratios (monthly earning to spending), net worth, reliability (duration of employment and residence), and other factors that determine the credit-worthiness of applicants. However, first I will create a module that handles the credit determination and have this module call other modules for the various credit calculations. This way, I can easily isolate problem code and even later easily add new credit calculations that the department might require.