Developer/CodeStyle

Contents

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 <FILE_NAME>

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

Templates

Use the following templates for your files:

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 <vector>), 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

Object Handling

  • If the structure you are implementing has an id, the derive the object from Named (<SUMO_HOME>/src/utils/common/Named.h). This class supports the std::string getID()-method.
  • If you want to store something in a map pointing from string ids to object instances, then use NamedObjectCont (<SUMO_HOME>/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:

Subversion properties

We set the following properties for the different file types:

  • Source files (".h", ".cpp", ".py", ".pl", ".java", ".am")
    • svn:keywords "HeadURL Id LastChangedBy LastChangedDate LastChangedRevision"
    • svn:eol-style "LF"
  • Test files (".xml", ".prog", ".complex", ".dfrouter", ".duarouter", ".jtrrouter", ".netconvert", ".netgen", ".od2trips", ".polyconvert", ".sumo", ".meso", ".tools", ".traci", ".activitygen", ".scenario", ".sumocfg", ".netccfg", ".netgcfg")
    • svn:eol-style "LF"
  • Windows only files (".vsprops", ".sln", ".vcproj", ".bat", ".props", ".vcxproj", ".filters")
    • svn:eol-style "CRLF"

Furthermore we delete the svn:executable property for all file types mentioned above except for ".py", ".pl" and ".bat" and delete the svn:mime-type property for all types above.

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

This page was last modified on 5 January 2012, at 13:13.