[Closed] 10 things every max plugin developor should do

Here are some tips that I feel may help the overall quality of software written for 3dsmax. I have targeted those writting plugins using the c/c++ sdk. Most of the principles are very general and could apply to any project, but I feel they need to be discussed since there are so many people targeting the max SDK now a days.

1. Compile your plugins at warning level 4! Microsoft has done millions of programmers a disservice by making the default warning level for c/c++ programs compile at warning level 3. And unforunately, many max plugin developers still have no clue that they are missing out on quality by NOT compiling at level 4.
   Note, you will have to take into account certain work-arounds to ignore asserts from the rest of 3dsmax. This is usually done by wrapping #pragma warning (push, 3) , #pragma warning (pop) calls around all plugin code at the file location that includes the maxsdk header files)

// foo.cpp
#pragma warning (push,3)
#include "max.h"
#pragma warning (pop)

2. Assert Assert Assert! Put asserts everywhere in your code to detect bad condititions. You can either: spend hours and hours in a debugger trying to solve impossible problems, or you can spend 3 seconds fixing them when an assert pops up in your face telling you where the problem is.

3. Keep your cyclomatic complexity down! Code is easy to write. It is nearly impossible to read, especially if the cyclomatic complexity of your functions is really high, and your nesting level is very deep. Remember, you wrote the code, but you may not be the one to maintain your code. If you give your code to someone else to maintain, the chances are very high that they will screw up your code while maintaining the beast. Therefore keep your functions simple, and small enough that they fit on maximum of two computer screens.

4. Don’t dump all your code in once large cpp file. Navigating large cpp and header files is a drag. Some code is only navigable by using Intellisense, or Visual Assist. It shouldn’t be that way. Remember code should be readable for a human first, and a computer second.

5. Check for memory leaks! Unforutnately many developers still don’t check their code for memory leaks using a profiling tool like Purify, AQTime, Bounds checker or the Debug CRT library.

6. Be paranoid with pointers! Assert pointers before they are used, use conditional guards to protect against bad pointers, NULL them out on initialization, and NULL them out when your done with them. But most importantly, NULL NULL NULL them!

7. Read books on coding standards! Books such as Code Complete 2 by Steve McConnell should be burned and seared into every programmers brain. Effective C++ by Scott Meyers should also be required reading. The book ‘C++ Coding Standards’ by Herb Sutter and Andrei Alexandrescu also lists standards everyone should be familiar with.

8. Instantiate Plugins in ClassDesc::Create, not statically. It is the habit of many old time plugins to instantiate a plugin once staticalliy, and in the ClassDesc::Create method to return the address of the static plugin. But what happens if some poor sap loads max with your plugin, but never uses it? You have just wasted all that memory with your plugin since the DLL was loaded (hence the static allocations), but if the ClassDesc::Create method is never called, that static allocation is sitting there wasting memory. Instead return a newly allocated instance of your plugin in ClassDesc::Create by returing new <your plugin>().

9. Write unit tests. Unit tests are the future of software quaility. Plugins that don’t have them are in the stone age. There are many unit test frameworks out there for native and managed code. For native code there is CppUnit, and WinUnit. For managed code there is NUnit, as well as the test framework that comes with visual studio team edition.

10. Measure Code Coverage! The absolute key to software quality is to test the code. Code coverage tells you what lines of code were executed while the Unit tests were executing. Without a tool to measure code coverage, a software product is guaranteed to not be fully tested. And when it’s not fully tested, it’s guaranteed to have bugs.

Thanks

Chris Johnson
(P.S.) Guys, perhaps this could be a sticky post?