ROBUST SOFTWARE HOW TO ADD QUALITY INTO YOUR SOFTWARE PROJECTS

Fabian Meier, G-Lab GmbH / GENEVA

16. Sept. 2014

Bio Fabian Meier

• Physiklaborant, Festkörper-Physik, 1988

• B.S. Elektrotechnik, HSR Rapperswil, 1995

• M.S. Electrical Engineering, Northwestern University, USA, 1997

• 7 Jahre als Entwickler: Video compression, Embedded software,

Streaming

• 4 Jahre Silicon Valley (Silicon Graphics, Burst.com, Verb Inc)

• 3 Jahre BridgeCo AG, Dübendorf

• Seit 2005 G-Lab GmbH, Product Management & Entwicklungsleitung

• 2009/2010 Aizo AG (DigitalStrom) – Patents

• 3 US patents in Image compression

• Software: C, C++, Java, C#, Assembler, Perl, Python

Some past software projects

Programming

• Video and image compression validation for chip (Perl)

• Video decoder – embedded on chip (assembler)

• Streaming server, Java

• Internet radio, C embedded

• Fully automated product test framework (Perl)

Manage development:

• Model XXL – 5 software (C embedded)

• AeroSphère Product line – Networked, Streaming: 3 systems, 2 Apps

• Distributed teams in different locations

Why does robust & high quality software matter?

• Target audience: “normal” scientists & engineers

Reasons

• Correctness

• Save development time

• Cost

• Pride

Pic Sailboat

Why robust software matters

Actual coding time: 70% - 30%

Fig 22-1 [1]

Bag of Tricks (Selected Best Practices) Systematic approach – learn from the past & other people

Defensive Programming

I. Architecture

II. Craft

III. Automatic error detection

IV. Add Robustness

Dealing with the real-world

I. Debug help

II. Process

III. Automatic Testing

IV. Tools

Selected Advanced Topics

Optimizing

Embedded programming tips

When does this matter? For which projects should I apply these best practices?

• 1 day: NO

• 1 week: NO

• 1 month: SOMEWHAT

• 2+ months: YES

• 2+ people: YES

Pic ARCHITECTURE

Architecture

I. Architecture Defensive Programming

• A4

• Use different views

• Avoid “clever” design

Pic Craft

Craft

II. Craft Defensive Programming

• What is the “art of software craft”?

• For example: Good naming: files, functions, classes,

variables

• calculateVelocity() vs. F1() or calculate()

• int averageVelocity , Vave vs. v1, avVel

Functions & Methods

• Size: Max size of function - 1 page, 50 - 150 lines + a few

longer ones

• Naming: verb + object, or describe return value:

• Good: printDocument()

• Bad: processInput(), f1(),

• Good: readMagnetSensors()

• Structure: split functions into a few blocks - mark with

comments (Step 1: do - xx....)

• Comments: why and what (step), not how

• Macros: minimize use, use functions. Debugger friendly,

compiler checks.

Variables

• Initialization: always, meaningful values.

• Naming: noun, 6-14char. Keep changing (IDE helps),

• Integers: check for division with zero & overflow

• Floats/double: don't use x == x (accuracy!!!)

• Strings: • NULL / 0 (terminator)

• Strcmp -> strncmp

• Size = L + 1 (null)

• Init with NULL

• Pointers: avoid (C#, Java, Python…) • always check for NULL

• always initialize to null

• embedded & drivers - worse effects

• Globals: OK, use them cleverly

• - naming, gA

• - add access routines/functions: getA(), setA()

Pic Mausfalle

Automatic Error Detection

III. Automatic Error Detection Defensive Programming

• Compiler

• Add tools to catch bugs: range check macros

CHECK_RANGE(a, 0, 254, MOTOR, “var a”)

• Strategies:

A) Stop execution

B) Report only

C) Report and recover

• Exception handlers

Error Detection - advanced

• Periodic health checks

Pic Man with many helmets, overprotected

Adding Robustness

IV. Adding Robustness Defensive Programming

• Expect the unexpected

• State machines: handle „impossible“ cases

• Exit gracefully

• Error handling concept (exception handler)

Pic – hunter hunting snakes or bugs, black and white.

butterlfly

Debugging help

I. Debugging help – finding errors more easily Dealing with the real-world

• Add logging facility • Print out: console or/and logfiles

• - One line with:

• (Time)(Error/warning/-)(intention/space)(Module)(details)(parameters) 12:01.234 ERROR Motor:StateMachine: invalid value A=34

12:01.238 Motor:Driver: state=start

12:01.674 WARN Heartbeat: overload v=45

•

LOG(LEVEL2, MOTOR_STATEM, (“invalid value A =%d“, A))

• Option: select verbose levels (0=off, 1=some, 2=more, 3=a lot of details)

• Option: select Module

• Statistics: error count

• Use #defines and Macros

• Interactive shell (terminal)

Pic process

Process

II. Process Dealing with the real-world

• Reviews

• Rule 1: find bugs

• Rule 2: reviewer accepts current design

• Concept of the two Hats [2] (Refactoring)

• Hat 1: Add features

• Hat 2: Fix bugs / change existing code

Pic automated testing

Automated Testing

III. Automated Testing Dealing with the real-world

• Essential part from „Software refactoring“

• Ideal world vs. Real world

• How to do it in small projects

• If?

• What?

• When: From the beginning

• Why?

• Possible approaches

• A) Input, process, compare output

• B) API, more complex testcases

• C) GUI

• D) Integrated

Pic tools

Tools

IV. Tools – your friends Dealing with the real-world

• Compiler

• Debugger

• Diff (Araxis merge)

• Git / revision control (github, bitbucket)

• Bug tracking

Pic optimizing

Optimizing Code for Speed

Optimizing Code for Speed Advanced Topics

• Compiler: -o, -o2

• Measure with a profiler – don‘t speculate

• 20/80 rule (5/95 rule)

• No fancy tricks

Pic embedded

Embedded Software

Embedded Software Tips Advanced Topics

• Automatic state machine generation

• Debug: Logging

• Debug: Use scope: use LED / GPIO’s

• Debug: Debugger

• Init/shutdown

• Memory: allocate static, at beginning

• malloc: Allocate memory at beginning (Memory overwrites with pointers)

• Classic model: main loop, state machine(s), interrupt handler

• ”volatile" for state variables

• Add robustness: expect unexpected timings, broken sensor, not possible states.

• Watchdog

Recommended Reading

• [1] Code Complete 2nd Edition, Steve McConnel

• [2] Refactoring, by Martin Fowler (Improving the design of existing code)

• [3] O‘Reilly Cookbook Series: Arduino, Python, Java...

• [4] The art of software testing, Glenford Myers (first 100 pages)

Pic magic tricks

Summary

Checklist for Software Project Mix and match! Use from the beginning.

• Architecture (1 page, different views, overview)

• Craft (naming)

• Craft – functions: naming, size, structure, few macros

• Craft – variables: init, naming, int, floats, pointers

• Craft - globals

• Automatic error detection (input/ouput checks)

• Compiler warnings

• Automatic health checks

• Error handling concept (report, stop, report+continue)

• Logging

• Interactive console/shell

• Process: reviews

• Process: two hats

• Automated testing

• Tools: diff, debugger, git, bugtracking

• Optimizing at the end

Questions?

Picture References

• Figure 22-1: Code Complete 2

• Sailboat: Robert Durfee, flickr.com

• Arduino: designSpark, flickr.com

• Architecture: Thomas Guignard, flickr.com

• Butterfly: Woodley Wonderworks, flickr.com

• Charlin Chaplin, Modern Times, flickr.com

• Optimizing: Michael Raby, flickr.com

• Mouse trap: Mark Louden, flickr.com

• Boat: UK Ministry of Defence, flickr.com

• Tools: Dan Thompson, flickr.com

• Magician: Pascal (pasukaru76), flickr.com