Linear Vs.Modular and Event Driven Coding


Programs in all languages can be divided into two categories: linear and modular.

Linear programs are ones that run from top to bottom. Modular programs are one where the code calls "functions" or "sub-routines", and the code often executes out of order. In a modular program, line 101 may execute before line 5.

When first coding in Python, programs are created to work in a linear fashion. In other words, the code works in a vertical line. Each statement is executed one after another. Some lines may be skipped (using the if statement), and some lines may be executed multiple times (using for while loops). But generally, the code runs from top to bottom.

The graphic below illustrates a simple linear program.

Diagram of a Linear Program

Figure 1: Diagram of a Linear Program

Even advanced programs or scripts may be linear. PowerShell scripts and database stored procedures may include very advanced and complex code, but still run in a linear fashion.

Modular Programs

Most modern programs are based on modular code, which breaks code up into small self-contained functions. The advantages of modular programs is discussed in this article: Modular Coding.

How does modular program code different from linear program code?

A modular program has a series of functions. A function is a set of coding statements that work as a block, and are independent from the rest of the program. The program has a main() function, that is often define first, but called last. main() is used to call other functions that do the work needed for the program to accomplish its goals. For example, there might be multiple functions to accept user input, functions to calculate some results, and functions to display output.

Diagram of a Modular Program

Figure 2: Diagram of a Modular Program

Design of a Modular Program

Modular programs should only have one statement that is not in a function. That is the call to main(), which is the very last statement.

The main() function should also be relatively short. It should NOT do a lot of "work". main() should call other functions to complete all the work needed for program.

The image below illustrates the basic design of a modular program. The main() function is defined first, followed by all the other functions. Note that other than main() being defined first, the other functions can be defined in any order. They will be called, if and when needed.

Diagram of an Expanded Modular Program

Figure 3: Diagram of a Modular Program

Event-Driven Programs

Programs may run without any user interaction. For example, there might be a batch program that reads an input file and creates an output file, that is run periodically on a schedule. No user interaction is needed. The program code could be either linear or modular, although modular programs are normally preferred.

Other programs, however, are event-driven. The program starts, but waits on some event trigger before anything else executes. Such programs do not necessarily require user interaction. Consider a program that monitors the water level for an irrigation system in a garden. Sensors in the tank monitor if the water is too high or too low. When a sensor detects one of those conditions, it triggers an event that is being monitored by the program. If the water is too high, for example, perhaps the program calls an overflowAlert() function (that starts an alarm and sends an SMS). If the water is too low, perhaps it calls a lowWaterAlert() function that does something similar. Note that the program may run for weeks or months without any event being triggered, and some functions may never get called if they are not needed.

User Interface (UI) and Graphical User Interface (GUI) Programs

Most of us are familiar with GUI (Graphical User Interface) programs. These are programs on any of our devices that present a "window" of some type, usually with colors, fonts, images and icons, and allow us to interact with our fingers, voice, or a pointing device such as a mouse.

A GUI program is a more advanced version of a UI (User Interface). There are still many devices that have a plainer UI, such as printers, routers, and perhaps your car radio. The difference between a UI vs. a GUI, is that a UI only has text, and only allows text input. There are no graphics (icons, images), usually no colors, and no ability to use other input devices. Another key difference is that a UI is always linear in terms of how the user interacts with it. The UI displays a statement or prompt, the user enters some text, and the UI displays the next statement or prompt. While the background code may be modular, the user interaction is always linear, in the sense that the user must select a next step provided by the program.

Most GUI's are very different. A web page, phone app, or desktop program, for example, may have many different options the user can select. The user is not normally required to do one thing before some other thing. The user selects an icon and the program executes whatever functions are needed for that option; sometimes it is just the presentation of a different GUI with more options.

GUI's are usually event-driven programs. The program waits on an event (clicking an icon or swiping) before it executes the next steps.

Data Entry Design Issues

One of the areas in which GUI's are very different from linear programs is in how data entry is handled. In a linear program, the user is prompted to enter data, and enters data for a specific item: "Please enter your first name:". Only after the user has entered the data (and it has hopefully be validated in some way), is the user presented with the next entry item.

GUI's often present the user with a "form", which may have many data entry fields, such as first name, last name, address, city, state, zip code, etc. The expectation is that the user will start at the first field and enter data in the rest of the fields in some order - but that it not enforced. The user could fill in zip code first, if they like, then move to any other field. That presents a coding issue for the programmer: should each field be validated as soon as the user enters the data, or should the program wait until the user is finished an clicks a Save or Update button, before validating all the fields at the same time?

Some programs attempt to validate each field as soon as the user indicates they are done entering data there (when the user moves to another field, for example). A program might check that the zip code entry was all numbers (in the U.S.), and display an error message if the entry was invalid.

In many cases, though, it is more common for programs to review all fields after the user has indicated they are done with the entire form. One advantage of this approach is that sometimes multiple fields depend on each other, and validating fields individually would not work very well. For example, if the user entered an address as London, Ontario, rather than London, California, the zip code should be allowed to contain letters and not only numbers.


Most modern programs are developed using modular code and are often GUI's. These type of programs work differently that linear programs, and different from plain UI's. GUI's often present different design and coding issues to handle tasks such as data entry and validation.