Paranoid Programming

May 7, 2001
Even paranoids can have enemies. And there is a place for paranoid behavior in design. Good programmers and engineers treat incoming data and signals the way a paranoid would—they don't trust them. Safety first—checking and validating...

Even paranoids can have enemies. And there is a place for paranoid behavior in design. Good programmers and engineers treat incoming data and signals the way a paranoid would—they don't trust them. Safety first—checking and validating data—is their watchword.

Basically, paranoia equates to good design practices, at least when fielding incoming data and signals. Of course, there's a price to pay. In most programs, there's a lot of code overhead in just checking the bounds, type, size, and value of incoming data and variables. Some estimate that such checks can take up to 10% or more of overall code. Moreover, this checking code is typically rife with branches, which slows execution.

Worse, this code—the checks and validations—tends to be error-prone. In C and C++, it's usually implemented as complex switches. Needless to say, these statements definitely aren't the fun part of coding (or debugging). They make up the "admistrivia" of programming, boring checks that must be done. Unfortunately, such complex switches also tend to be hard to read and maintain.

As a programmer (assembly and C), most of my problems came down to complex switches—i.e., complicated multiple branches based on selected values. Here, cryptic coding led invariably to my downfall. I'm not alone. Complex switch statements are the bane of most programmers. Also, they do most of the boundary checks, an error-prone activity. Other than input or algorithm errors, this is where most coding errors lurk.

Let's eliminate the problem. Let's automate complex switch and bounds-checking. This isn't hard to do. Just put an open table entry form in the IDE editor, which generates the code for compilation or assembly. This code is "correct by construction." Additionally, the open switch form is easy to read. It documents the what, why, and how of the switch. These forms let us see what we did. Even better, the test and maintenance programmers can see it also over the code's lifecycle.

Automating complex switch statements may not lead to scientific glory, but let's get efficient and let the software do some of the paranoid thinking for us.

Sponsored Recommendations

What are the Important Considerations when Assessing Cobot Safety?

April 16, 2024
A review of the requirements of ISO/TS 15066 and how they fit in with ISO 10218-1 and 10218-2 a consideration the complexities of collaboration.

Wire & Cable Cutting Digi-Spool® Service

April 16, 2024
Explore DigiKey’s Digi-Spool® professional cutting service for efficient and precise wire and cable management. Custom-cut to your exact specifications for a variety of cable ...

DigiKey Factory Tomorrow Season 3: Sustainable Manufacturing

April 16, 2024
Industry 4.0 is helping manufacturers develop and integrate technologies such as AI, edge computing and connectivity for the factories of tomorrow. Learn more at DigiKey today...

Connectivity – The Backbone of Sustainable Automation

April 16, 2024
Advanced interfaces for signals, data, and electrical power are essential. They help save resources and costs when networking production equipment.

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!