When writing code, you can only choose two of the following:

1. Code that is quick to write

2. Easy to read

3. Works well

At DB Services, we think it is more valuable to place a higher focus on readability of code that works well than quickness of writing. Since developers spend more time reading and debugging code than actually writing it, any efficiency we can gain through maximizing readability will add up quickly. This ultimately benefits the client because optimizing the readability of code gives the biggest bang for your buck.

Let's take a look at a couple ways we do this.

Template Scripts

When it comes to the application development process, humans are the most expensive part and conserving labor hours is the best way to lower costs. One way we do this is using templates for similar code when working on processes. With carefully crafted templates that use clean, readable code, we are able to save development time. Plus, the familiarity with the code we already know works allows us to get moving rapidly and accurately.

If we need to create something new with no similar code, using a blank template script helps to make a readable, robust script.

Good Comments

Commenting well is possibly the biggest part of writing scripts that are easy to scan and read by developers. To comment well, it’s important to create a high readability factor. High readability can be achieved by spacing out different parts of the code into blocks, preferably by thought process behind each block. Basically, try to keep everything related within a block and allow proper spacing between each block so there is a visual cue where each block begins and ends.

For example, the first block might be grabbing all the parameters and variables, the second block might be creating a new record and making sure that record is created properly. The third block might be creating related line items, and so on and so forth. It’s important to keep the spacing consistent so it is easy to scan. Indenting the section headers also helps separate the comments from the actual code.

Here is a side-by-side of the same script:

On the left is a well-commented script; on the right is the same script with no comments. In order to understand a script without comments, a developer has to read every single line to figure out what’s going on. If you comment well, then months later when you need to jump into the code, it won’t take nearly as long to decode what is going on.

Conclusion

Because developers spend so much time reading and debugging code, it only makes sense to take a little extra time at the front end of the process to create readable code. In the long run, that little bit of extra time at the beginning saves developers a lot of time and frustration down the line. All of which makes for a better product and better value for the client.

Please reach out to us if you need assistance creating readable code in your FileMaker application.