Developers and users can have different perspectives on code quality.

Geoff made reference to various holy wars in the history of computing, from the GOTO wars to to how many spaces in a tab indent.

Today we're focused on correct, bug-free code.

How much testing should you do? It depends on what happens if things go wrong.

Geoff listed some interesting examples of consequences with software failure, such as the Therac-25 radiation incident. With real time systems you don't get a second chance; testing is critical.

Test-driven development

Develop tests prior to or during development. TDD comes from Kent Beck and the Agile/Extreme movement. And because there are methodologies there are also holy wars, but there's lots of good here.

Clarion lends itself to iterative development.

Geoff gave an example of some test code that fails with a Stop() message, forcing you to acknowledge the failed test. If possible get someone else to write the tests. Test for edge/corner case - he gave a number of good tests for string replacement.

Geoff showed an excellent video illustrating the dynamics of refactoring...

Michael Jackson's rules of optimization:

Don't do it.
If you must do it, don't do it yet.

Knuth: premature optimization is the root of all evil. But don't pass up the 3% that needs to be done. Find the slowest part of the program and make that part faster.

Recommended book: Programming Pearls.

All changes have some risks. When you add new functionality, refactor. When you add a bug fix, add new tests.

Code smells are an indication that something is wrong. If you're logging bugs and you notice that you're getting a clump of reports, that's a code smell. There are lots of others - see Wikipedia. Martin Fowler says the number one code smell is duplicated code.

And speaking of duplicated code, Geoff finished off with a discussion of code analysis using n-grams. What does Google n-gram corpus have to do with code optimization? Can we use n-grams to detect duplicated code? There are challenges - indents, split lines, case inconsistencies etc.

Geoff demonstrated a utility he wrote (available to conference attendees) that standardizes Clarion code and provides various ways to query the data. Geoff then showed how he used the utility to find a massive block of mostly-duplicated code inside a single procedure.

Browser not supported