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?

Comments

• Anonymous
  January 09, 2004
  The comment has been removed
• Anonymous
  January 09, 2004
  Johan mentions the nonsense regarding exceptions, but what's missing here is use RIIA (resource-initialization-is-acquisition).
  
  This is one of the things that makes exceptions safe; all your resources are freed when your destructors run as the stack unwinds.
  
  Of course, the CLR doesn't exactly offer this (other than try/finally, which C++ doesn't offer), so I can see how you'd forget about this after spending so much time in the managed world :).
  
  You could also take this a step further - use <algorithm>. Particularly things like for_each.
• Anonymous
  January 09, 2004
  >* Always initialize variables when you declare them
  >
  >> use smart types that initialize themselves
  
  Most people don't use smart types for things like int and bool so the guideline is still needed. (And many existing smart types like CComXxx stuff in ATL require their own set of guidelines to be used safely).
  
  My favorite unmanaged guideline that goes away in managed code:
  
  Don't do anything non-trivial in DllMain or global C++ constructors.
• Anonymous
  January 09, 2004
  The comment has been removed
• Anonymous
  January 09, 2004
  The comment has been removed
• Anonymous
  January 11, 2004
  I would like to comment on typesafety of managed code - it only offers runtime typesafety, not compile time. It will change once generics are implemeneted but meanwhile we have to explicitly catch System.InvalidCastException in cases where C++ templates would throw compile time errors. Personally this bugs me a lot more than remembering to use safe string APIs...
  
  Oh and what's the hidden cost of foreach (except an enumerator being instantiated)?
• Anonymous
  March 21, 2004
  gjgdjggngmkhhhk