Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction

As in all things, you are free to choose your own policies; however, here are some suggested best practices for various development tasks in FireBreath. This is a work in progress; if you have items that should go on this list, please add them. We'll remove them if we don't like them =] Feel free to leave comments if you disagree with something on this list.

Dealing with JSAPI objects

  • Never use a JSAPI object by reference or by raw pointer; always use it wrapped in a boost::shared_ptr or boost::weak_ptr
    • If this feels like a lot of typing to you, consider adopting the FireBreath convention of typedef boost::shared_ptr<ClassName> ClassNamePtr and boost::weak_ptr<ClassName> ClassNameWeakPtr;
  • Never store a shared_ptr to a JSAPI object except inside a class that owns that object. Otherwise, use a boost::weak_ptr. This will help prevent memory leaks due to cyclic dependencies
  • Avoid using multiple inheritance on a JSAPI object! Consider using a "has a" instead of an "is a" relationship.

Plugin project management - files, dependencies, targets, build machines

  • Don't add files, dependencies, or link libraries to your project from inside your IDE
    • "But wait!" many cry, "Our build server doesn't have CMake!" Regardless of your reason for not liking CMake, get over it and just install it and use it as intended. It's up to you -- but don't come complaining to use when you find that you have caused yourself far more work than you saved by not learning to use CMake.
  • Don't move your build directory. Delete it and run the prep script again.
  • Don't put your build directory in source control. Run the prep script on each computer, each platform
  • No labels