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

TTI Transportation Resource Center

April 8, 2024
From sensors to vehicle electrification, from design to production, on-board and off-board a TTI Transportation Specialist will help you keep moving into the future. TTI has been...

Cornell Dubilier: Push EV Charging to Higher Productivity and Lower Recharge Times

April 8, 2024
Optimized for high efficiency power inverter/converter level 3 EV charging systems, CDE capacitors offer high capacitance values, low inductance (< 5 nH), high ripple current ...

TTI Hybrid & Electric Vehicles Line Card

April 8, 2024
Components for Infrastructure, Connectivity and On-board Systems TTI stocks the premier electrical components that hybrid and electric vehicle manufacturers and suppliers need...

Bourns: Automotive-Grade Components for the Rough Road Ahead

April 8, 2024
The electronics needed for transportation today is getting increasingly more demanding and sophisticated, requiring not only high quality components but those that interface well...

Comments

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