My recent study of the defects that slipped through reviews but were found during testing show an interesting pattern: they were almost all due to timing issues. Could a change of programming style reduce those errors?
I guess it isn’t surprising that these were the errors that were left. Most game code is written in a mixture of C and C++ and my current project is no exception. Compilers for statically typed languages like the C family find most typos and syntax mistakes at compile time. Because games are real-time applications most of the code is simple as it is executed many times a second. Obvious mistakes that bypass the compiler still tend to show up quickly.
This leaves a class of defect that’s particularly difficult to find in either review or compile. Symptoms of these defects are still usually immediately obvious, but tracking down the cause is more time consuming than with other kinds. I think the reason such defects evade reviews is that to see the problem requires a global understanding of the code. Review checklists are very good at picking up syntax mistakes and obvious typos. They are not so good at detecting order of execution defects in messages between dozens of separate objects.
The functional programming style avoids many synchronisation problems. Functional programming differs from imperative programming in that you don’t describe the order you want your program to run. Instructions could be executed on different processors or in different threads, which is fine since functions are not allowed side effects. I’ve been looking at the Haskell language since this is the most developed of the pure functional languages.
Although I don’t think I’ll be converting all my programs over to Haskell any time soon, I am looking at coding in a more functional style within C. Avoiding side-effects in functions should be easy, but avoiding mutable data… well that’s another story.
