Miniature/Policies

(→Coding style)
(→License)
Line 3: Line 3:
= License =
= License =
-
Miniature will use the GPL 2 or later variation, since the GPL 3 might conflict with the Harmattan Security Framework or Ovi. Artwork can use a CC-style license, minus the NC clause (again: Ovi store, maybe).
+
Miniature will use the [http://www.gnu.org/licenses/gpl-2.0.html GPL 2 (or later)] for source and header files. For art contribution, Miniature will use the [http://creativecommons.org/licenses/by-sa/3.0/ CC-by-sa].
= Coding style =
= Coding style =

Revision as of 21:37, 11 November 2009

This is a list of things we agreed upon in the Miniature team. TODO: List the items that are *not* fully agreed upon yet!!

License

Miniature will use the GPL 2 (or later) for source and header files. For art contribution, Miniature will use the CC-by-sa.

Coding style

We do not need project-wide consistency, but be at least consistent inside a module and/or file.

Note: the current code violates this style. We will fix it.

We mostly try to follow the offical Qt Coding Guidelines, but with some exceptions.

  • We use whitespaces over tabs.
  • Max. length of a source code line is 120 characters.
  • We use a Miniature namespace for all our components, and all our types(classes + typedefs) start with M.
  • Types are in MCamelCase.
  • Method names are in mixedCase (= lowerCamelCase).
  • Braces after newlines.
  • Variable names should be visually different from types (even if you use an editor w/o syntax highlighting), there_fore they have under_scores, no caps, no lower_Camel_Case.
  • Member variables should be visible, either m_* or *_ is fine. Just be consistent inside a single impl file.
  • We use no_keywords, for now. We want to avoid those function-style macros.
  • Impl files have a .cc extensions, header files use .h
  • Use Qt containers over std containers.

How to keep code testable (and hopefully, mostly bugfree)

We want to have testable code, therefore we also want to follow some advanced coding standards.

For that, I will try to list some really really useful advice from this document: http://www.research.att.com/~bs/JSF-AV-rules.pdf, a coding style document for C++. Bjarne Stroustrup worked on that one, yes.

  • Keep methods at a reasonable length. In general: If it doesn't fit on a screen page it's probably too long. More precise: Every method longer than 200 lines of code (including comments, yes) is too long.
  • Within a method, avoid a cyclomatic complexity higher than 20 (see Appendix A regarding AV Rule 3, pp. 65, "Cyclomatic complexity measures the amount of decision logic in a single software module.", and the example).
  • Avoid cyclic dependencies between classes/modules (Rationale: it's mostly an indicator for layer violations).
Retrieved from "http://wiki.maemo.org/Miniature/Policies"