top bar

Micro-Manager Coding Style and Conventions

Revision as of 11:55, 11 December 2009 by Arthuredelstein (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Formatting and style

  • All indents are 3 spaces (no tab characters).
  • Curly braces open in the same line in Java an in the new line in C++ (see examples).
  • Class names begin with uppercase, and with each word capitalized, e.g. MyFirstClass.
  • Function names use the same convention except that in Java they begin with lowercase and in C++ with uppercase, e.g. MyFunc() in C++ and myFunc() in Java.
  • All variables begin with lower case, e.g. myVar.
  • Class member variables begin with lowercase and end with underscore, e.g. memberVar_.
  • Do not use this->memberVar_ idiom unless it is absolutely necessary to avoid confusion.
  • Static constants in C++: const char* const g_Keyword_Description.
  • Static constants in Java: static final String METADATA_FILE_NAME.

Comments, headers, etc…

  • Function/class headers use documentation JavaDoc convention (see examples).
  • The code should be clear and self explanatory.
  • Use comments to explain algorithms and anything that is not self evident.
  • Function headers should explain the “contract” with the caller if it is not totally clear from the function signature (parameters). In general all public methods should have headers.
  • Use common sense and avoid unnecessary headers and comments for code that is obvious.
  • In general, do not enter revision history comments in the source code, nor in the file header. They impair readability and break the visual flow.

Revision/change tracking

  • Only the latest version matters. Keep the code elegant and simple (both visually and functionally).
  • Use source code control to retain the revision history in the particular file, i.e. check in the SVN often and each time enter the revision history comment.
  • Work incrementally. Make small changes and make sure the code compiles. Check-in after every major step to retain revision history.
  • Check-in at least once each day, unless there is a strong reason not to…and there aren’t any.
  • If there is a danger of destabilizing the main application, open a branch and work in it for a while, but still check in at least once each day.
© Micro-Manager : Vale Lab, UCSF 2006-2011 | All Rights Reserved | Contact