Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Enbugging

swatts
Active Participant

Hello Lovelies,

If you've read some of our articles you'll be aware of our thoughts on Codes Smells and Anti-patterns. We think the term enbugging is a very elegant addition to this lexicon.

This article is based on the article by the Pragmatic Programmers.

A bug creeps into your code, it's not your fault it's just a bug, a gremlin, a random happenstance....

Or that's what we tell our bosses.

That's the easy way out, a bug is a mistake, it's a mistake in understanding, a bad design decision, an over-complication. The only people who don't make mistakes are not doing anything. We're very suspicious of people who don't make mistakes!

Sometimes you can have a day when you seem to actively putting bugs into the code. Welcome to the world of enbugging.

It's usually takes some setting up to have a really good enbugging session, decisions that are made days before cumulate into a world of pain. Removing 1 bug will generate 2 more. It's a recipe for stress and worry.

The techniques in the article for reducing enbugging talk about encapsulation and information hiding, writing "shy code".

In OOP an object responds to messages and these messages should follow the rule "Tell, Don't Ask". In LCOD we call our enumerated type a command and not a query. We are telling our object to do something, it may respond with some data or it may not. It's internal data is private.

Also minimize how much our objects chat to each other, keeping the data shared by our objects to a minimum (coupling) also makes it more difficult to put bugs in. Generally less shared data equals more predictable code, easier testing and less bugs.

Bugs like to hide!, you can help the enbugging process by giving them lots of places to hide in. Large block diagrams, making lots of decisions are a wonderful, fertile bug garden.

Small Testable VIs are more akin to a desert.

A cluttered block diagram is also a wonderful place to hide bugs. A clean, easy to understand block diagram makes enbugging far harder.

If your bag is dynamic loading make the dynamically loaded VI cohesive enough to be tested.

In fact a lack of testability is a wonderful way to grow bugs. If testing is hard you need to be pretty damn sure of yourself!

Bugs can easily placed in arrays, logic, maths and my own particular nemesis dates.

So where else is the best place for bugs to lurk?

Lots of love

Steve Watts and Jon Conway

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments