I'm taking a class this week.  The subject is writing WDM drivers.  The class assumes you have some understanding of how operating systems work and teaches you everything you need to know to be prepared to write a WDM driver.  It isn't a cookbook class.  I won't come out and write a driver without needing the DDK but I will have enough understanding to be able to read the DDK and fill in the connections between all of the parts.  I find that when trying to learn something, rather than being told exactly what to do, I learn best by getting a high-level view first and then diving into the details.  This class is taught in that way and I highly recommend it.  The class is offered by OSR.  It is being taught by Peter Viscarola (author of Windows NT Device Driver Development).  If you are new to driver development, take this class.

   The class isn't the main point of this post, however.  Rather, it is some advice that Peter gave a few times during the class.  Someone might ask a question like "Can't I do x in some funky way?" and he would answer, "You could, but no one would expect to see it so don't."  The point he was making is that we, as programmers, should stay away from being clever.  We should, as much as possible, try to do things the same way everyone else does them.  Why?  Because you won't be the only person to work on this code.  Even if you are, the next time you touch it might be a year or two from now.  If you did something clever, the next person to touch it will look at the code and not immidiately understand.  This will have one of two consequences.  Either they will have to spend 10 minutes just trying to understand what it is you did or, worse, they will assume you made a mistake and "fix" it by making it less clever.  Neither of these results is desireable.  Unless you are writing one-off code for yourself* you need to write it in a manner to make it easily understandable so that it can be easily maintained.  This is the intent of the smell test talked about by the authors of Refactoring or of the self-documenting code the XP advocates talk about.

   To be more explicit, whenever possible, follow conventions.  If you aren't the first one to be doing something, don't reinvent the wheel.  If you aren't sufficiently familiar with your domain to know the conventions, it would behoove you to spend some time becoming familiar with how things are done in that space.  Doing so will save lots of time and effort later.

 

* Useful one-off code often ends up not being one-off code.  Always code like you'll be maintaining it.  Someone probably will.