Patch Checklist

From Rigs of Rods Wiki

This article can be downloaded as PDF

Checklist for Bugfix patches

General

• use all Ogre functions if possible (Ogre::String, Ogre::Real, Ogre::StringConverter, etc)
• do not use c++ string streaming
• do not mix c++ std::string with Ogre::String, even if it works. (also dont mix wxString with anything if possible)
• do not abuse STL: use basic STL only: std::vector, std::map, etc. Do not create big template classes yourself.
• prefer static allocation instead of dynamic (to prevent memory leaks)
• use C++ classes if possible, to separate code from the rest.
• if useful, use c++ design patterns: singleton, factory pattern, ...
• do not use global variables if possible
• do not use precompiler definitions if the problem is solve-able dynamically with not too much overhead.
• use the SETTINGS macro to read custom configuration settings
• if you add new configuration settings, keep in mind that the configurator has to be updated as well at some point.

Documentation

• document all your classes / functions, so they show up properly in the doxygen generated documentation
• update this page: Patch Authors

Stability – keep it stable

• No known bugs
• No known network desyncs
• Checked by other people
• Checked in full length game
• checked against memory leaks: be sure to delete all the stuff you create again: Ogre and memory wise!

Complexity – keep it simple, straightforward, and easy to understand

• KISS principle
• Only one new feature per patch
• Complex algorithms and tricks explained in comments
• No unnecessary tricks
• Adequately commented

Attitude – please be nice to the devs!

• Remember this is 100% volunteer work. The devs do this in their free time.

Style – please stick with the Coding style rules!

• Functions
• Variables
• Enumerations / static consts
• Control flow
• Classes
• Templates
• Other rules
• Documentation
• Other tips
• indentation

Checklist for Feature patches

• same as the list above for Bugfix and:
  • written down design of the new component in the wiki. For example if you are going to improve the engine code, we would like to see a long term plan in your patch realized
• least impact on main RoR Code:
  • new feature is completely optional
  • does not brake backwards compatibility
  • do everything in your own class if possible, least code changes in the main RoR files.