Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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. 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. 

He once found a bug in InString while doing his own string testing. It was fixed in a later Clarion release. 

If possible get someone else to write the tests.

Test for edge/corner case - he gave a number of good tests for string replacement.

Excellent video illustration of refactoring...

Michael Jackson's rules of optimization:

  1. Don't do it.
  2. 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: the Programming Pearls books.

All changes have some risks. When you add new functionality, refactor.

When you add a bug fix add new tests.

Code smells - 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. 

What does Google corpus have to do with code optimization? Can we use ngrams to detect duplicated code? 

There are challenges - indents, split lines, case inconsistencies. Geoff worked on a way to standardize Clarion code. He processes the code into ngrams and has various ways to query the results. He demonstrated finding a huge block of duplicated code in a single procedure. 

 

 

 

 

 

  • No labels