Ideas in Wiring

Danger of preserving conventions

Code can be written in many different ways. There are snippets of LabVIEW code that I can look at and know the original author. The way they write their comments, the way they name their variables, and other telltale signs. I say the original author because the person who first writes the code tends to lay down the template for how the code is modified in the future. Mismatching styles in the same file cause complete chaos. You can't have three methods of error checking in the same function or else the code becomes indecipherable and hard to maintain. Therefore, modifications to the code tend to be written to match the original style, even if they are made by a different person.

This preservation can be a problem over time. There may be a technique that is better than the style being used but, since you don't want to mix the styles, you may need to change everything over to the new style rather than just a snippet. That takes work.

Sometimes, the operating environment changes out from under you and the old style is actually incompatible with the new operating environment. Recently, someone found a bug in LabVIEW that I thought was amusing. In the older Unix systems, after you call some system calls you read a variable called "errno" to see if the call succeeded. Windows followed the same convention but you called a function, GetLastError(), instead of reading a global. As developers, we try and keep the style the same so that style got reused in one of our libraries. It had a GetError() function. Wellllll.... errno isn't thread safe unless you do some special things. Our library didn't do these special things and therefore it wasn't thread safe either. When that library started getting called from multiple threads, bad things happened.

What's the lesson here? Following style is good, blindly following style is not. Question authority!

posted by Joel @ 7:42 PM