Wiki

Clone wiki

OscaR / CodingStyle

Coding conventions (draft)

This page aims to centralize coding conventions that should be followed when writing code in OscaR. We try to follow the official coding conventions of Scala described [here](http://docs.scala-lang.org/style/naming-conventions.html). You\'ll find here under some guidelines more specific to OscaR.

Comments

Of course every non trivial comment is welcome. The most important ones that should be in the code is any literature reference related to the implementation.

Headers and primary author(s) name(s)

Don\'t forget to add the LGPL license. In addition you can add you author name as advised in the famous book \"The Pragmatic Programmer: From Journeyman to Master\". It means you are proud of your work and you feel responsible of the maintenance of this file (most of our source files should thus have a primary author).

In case someone is modifying \"initial\" code:

  • If it is not substantial, there is no need to add your self as an author of this file.
  • If you consider it is substantial (meaning for instance that you think you have spent as much time on it as the primary author), then you can probably add your self as an author as well.

In case of doubt, I think the \"The Golden Rule\" is probably to ask to the original author the permission for that.

As a an open-source project, based on the good-will and motivation of people only (mainly working during their free-time), it is important that every body\'s work is recognized appropriately and this is why I suggest to follow this rule.

Parameter and identifiers for numbering objects

Quantities and numbers are particularly common in models. Usually, numbers are named with the prefix n or nb. In OscaR, the prefix n should be preferred:

Range

In models, range are commonly used to represents a set of numbered items. Hence we chose to name a range with an upper case first letter:

Constraints modeling and operator overload

Among the different modeling and sub-libraries of OscaR we try to keep those DSL syntax guidelines for adding constraints to a model:

Updated