PDA

View Full Version : 10 things every max plugin developor should do


AlpineMan
03-25-2009, 01:21 PM
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?

Dubbie
03-27-2009, 09:04 AM
Thankyou very much for this post. To a self-taught coder, this stuff is gold.

StephenT
05-27-2009, 09:20 PM
Number 11: read the documentation.

I don't mean the SDK documentation (although that kinda goes without saying)... but the product documentation itself.

What does function X do? Search for it in the product documentation, you might be surprised what turns up. Also - understanding how different classes in max interact (and what they do) is far easier to see visually, than it is to describe in the SDK.

Besides - max is kinda fun! Playing around with it shouldn't be too much of a chore :-)

scorpion007
06-04-2009, 02:05 AM
Let me just add to that by telling the SDK team to follow those same practises. Does the latest SDK compile cleanly under /W4 yet? The code samples don't show best practises very often, IIRC.

Also, please, please tell the doc writers to proof-read the docs before shipping them! Especially the code snippets, there are typically the most broken.

Oh, and the volume of documentation really needs to be increased. More guide information, and more in-depth reference information.

BTW, the just-published docs for 2010 are a big improvement over the old ones, so you're on the right track.

AlpineMan
06-04-2009, 09:34 AM
Let me just add to that by telling the SDK team to follow those same practises. Does the latest SDK compile cleanly under /W4 yet?

We are aware of this, and have made it a priority this time around to look at this.


The code samples don't show best practises very often, IIRC.

Also, please, please tell the doc writers to proof-read the docs before shipping them! Especially the code snippets, there are typically the most broken.

Oh, and the volume of documentation really needs to be increased. More guide information, and more in-depth reference information.

BTW, the just-published docs for 2010 are a big improvement over the old ones, so you're on the right track.

Thanks. I'll Let Chris Diggins know. Or you cold let him know yourself, over on the Max SDK blog on the area.

CGTalk Moderation
06-04-2009, 09:34 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.