Developer/CodeStyle

= C++ Code = For the C++ code we use AStyle to keep indentation and other whitespace usage consistent throughout the project. In order to make your code appear same as the original SUMO code use the following call to AStyle (or execute tools/build/apply_astyle.py before committing): astyle --style=java --unpad-paren --pad-header --pad-oper --add-brackets --indent-switches --align-pointer=type -n 

Still, there are several other things you should keep in mind:

Templates
Use the following templates for your files:
 * Developer/CppFileTemplate
 * Developer/HFileTemplate
 * Developer/PyFileTemplate

Variable Names

 * Variables used within methods should be named using "camel-caps", f.e. "currentCarVelocity"
 * Member variables should additionally have the prefix "my", f.e. "myMaximumVehicleVelocity"
 * try not to abbreviate variable names
 * give names to variables which describe its purpose within the context
 * do not reuse variables for different purposes

#include-statements

 * do not use backslashes (\)! use slashes (/) only
 * do not use absolute paths!; something like #include "/home/daniel/mylibs/include_me.h" will never work somewhere else! Use relative paths and tell the compiler where the other libraries may be found. If you have problems on this, please tell us, we'll write some further documentation!
 * in general we mention the standard library includes first (like #include ), then the includes of libraries used by SUMO (FOX / Xerces) and later our own headers
 * brackets ("<" and ">") are preferred for files not residing in the same directory, while quotation marks are usually used for files in the same directory.

"using namespace ..."-statements

 * Avoid them whenever possible and especially do not use "using namespace ..."-statements within the .h-files! It's possible that an included library tries to use a different impementation - who knows? Using a "using namespace ..."-statement within your .h-file may yield in an unexpected behaviour.

throw-declarations

 * We are not using throw-declarations, see: http://www.gotw.ca/publications/mill22.htm (thanks to Björn Hendriks); we'll remove the existing ones subsequently.

Object Handling

 * If the structure you are implementing has an id, the derive the object from  (/src/utils/common/Named.h). This class supports the  -method.
 * If you want to store something in a map pointing from string ids to object instances, then use  (/src/utils/common/NamedObjectCont.h).

= Python Code = We try to adhere to the PEP 8 Style Guide. Please remember to set the svn property svn:executable if (and only if) the file should be executable (i.e. is not a module to be imported by others).

Template
Use the following template for your files:
 * Developer/PythonFileTemplate

= Subversion properties = We set the following properties for the different file types: Furthermore we delete the  property for all file types mentioned above except for ".py", ".pl" and ".bat" and delete the   property for all types above.
 * Source files (".h", ".cpp", ".py", ".pl", ".java", ".am")
 * "HeadURL Id LastChangedBy LastChangedDate LastChangedRevision"
 * "LF"
 * Test files (".xml", ".prog", ".complex", ".dfrouter", ".duarouter", ".jtrrouter", ".netconvert", ".netgen", ".od2trips", ".polyconvert", ".sumo", ".meso", ".tools", ".traci", ".activitygen", ".scenario", ".sumocfg", ".netccfg", ".netgcfg")
 * "LF"
 * Windows only files (".vsprops", ".sln", ".vcproj", ".bat", ".props", ".vcxproj", ".filters")
 * "CRLF"

There is a python script checking (and optionally enforcing) this in tools/build/checkSvnProps.py.