Reflection on unmanaged coding guidelines

Recently I got asked to review a set of internal coding guidelines – unfortunately they were for unmanaged code… I admit it has been a while sense I have written much unmanaged code and I was amazed at how many guidelines are just taken care of in managed code. The nature of the CLR and languages just take care of the issue out of the gate.

 

Here are a few examples:

Always initialize variables when you declare them

You should also always initialize output parameters in a standard way. For example:

Initialize pointers to NULL

Initialize numerics to zero

In managed code, the CLR initializes references to null and numerics to zero even for value types. So this guideline is no longer needed.

Never do anything that can fail in a constructor- use an init method instead

In managed code it is perfectly fine to throw an exception from your constructor. The GC will guarantee the memory is freed and finializer is run if needed.

Use safe string API’s to avoid overwriting buffers

Many times some sporadic memory access violation bug will show up when the program is running. One of the sources of this that some string buffer might have been overwritten unexpectedly.

This is one of my favorites – With the typesafty of managed code and the modern design of the BCL this problem is all but eliminated. All the System.String APIs are safe!

Minimize the use of multiple implementation inheritance

This is a case of addition through subtraction principle. The platform is net better without this feature

 

What is your favorite unmanaged (C\C++, etc) guideline that just goes away in managed code?