Enbugging

[swatts]

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

[ohiofudu]

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

[Ian_Billingsley]

Another great post Steve...

Anywhere where data type conversion takes place is another bug favourite I find, particularly in the fpga environment.

[swatts]

yup keeping it tidy always helps (same in textual languages too)

[swatts]

That is a great example Ian.

For us one simple fix that has made an improvement is always error-trapping variants thoroughly and loudly. I guess this should need extending to all data conversions.

With FPGA I personally like to stick with the simplest data type I can and convert up as late as possible. What techniques do you use?

[crossrulz]

Where I have seen the most bugs in my previous life was definately overcomplication.  I inherited a project early in my LabVIEW career and everytime there was an integration issue, I removed code (along with some other very minor tweaks) to get it to work.  I still remember telling the original developer how to do a very simple test and his exact words to me were "That's too simple.  It'll never work."

Other common mistakes I have seen/done: mixing decimal and hex, constantly changing requirements, and stupid comparison logic errors (why did I use less when is should be greater?).

[samsharp99]

I think doing binary logic has to be up there on the list (often find myself probing every input to a compound arithmetic node!)

[swatts]

I sometimes view complication as macho programming. It's as if they need to demonstrate how very clever they are, the older I get the more tiresome I find that attitude.

We have a positive assertion rule for all logic (i.e. the outcome of the comparison etc should be positive). This has helped us a lot.

[swatts]

I've written about this a fair bit and agree completely. The fix for us is to insist that the sentence for the logic is written out in full (normally as a comment for the true state of a case). People argue that our practice of using nested case statements and look-ups is bad, but the reason for it is to keep logical statements simple (having a lot of simple logical statements is far better than one big complex one). Experience has shown this to be worth-while.

[samsharp99]

That's definitely a smart move and a tip I'll try to remember to do moving forward about writing down the logic statement in the block diagram!