How to prevent "fat finger syndrome" in absence of req. predeclearation?

Question

For example:

on rising edge (reset):
sync = defaultValue;
...
... various processing constructs ...
...
if (event == someEvent)   // Back at the Batcave
    // The vilianous Fat finger Syndrome
    // strikes again!
    synch = someEventProcessing()
...
... various processing constructs ...
...
someSyncProcessing(sync)  // Foiled again!

All occurances of the varible "sync" should have been spelled "sync" instead of "synch." I even read the line with the incorrect spelling and my brain "tokenized" it's symbolic meaning.

I looked at the code for a couple days before I found the typo. How do you prevent this when the language doesn't generate any errors? There was a work around in the code because somebody couldn't find the source of the "Black magic" causing the program's errant behavior. This obscurred the problem even more. (This code was actually paraphrased from a verilog program. But seems like it could be a problem in any language that allow this type of thing.)

Answer 1

If your compiler does not provide a tool to spot these kind of troubles, you don't have much to hope for. I would recommend a very strict unit testing policy. At least it will make it easier to pinpoint the syndrome occurrence.

A possible (NB: possible) strategy is to take all the unique identifiers, one by line (e.g. replace all spaces with returns) and then filter them through a sort | uniq. It will, hopefully, allow you to get a better view of strangely typed identifiers.

You can also reduce such occurrence by using tab-completion in your editor. vim, for example, has a very useful function (Mosh_tab_or_complete) to perform autocompletion.

Answer 2

Unit testing. Using TDD you write tests to define the expected behavior, then write the code to implement the behavior. Set up your expectations and mock objects then test that the mock objects had the correct methods called. Check that your data now has the correct values.

Answer 3

Just remember to take it slow. Too many programmers rush and make mistakes like this. I know writing in Verilog is not very user friendly so you have to be extra careful in this case.