Guidelines - grame-cncm/inscore GitHub Wiki

Coding guidelines

Source code organisation

The source code is located in the src folder. It is organised as follows:

  • guido2.ttf: the Guido font
  • emcc: bindings and specific code for the WASM library
  • faustarch: faust architecture file (copy to avoid faust dependency and obsolete)
  • imf: inscore xml export format (unfinished and obsolete)
  • inscore: the core library source code
  • inscore2: source code of the inscore language version 2
  • inscoreviewer: the viewer source files
  • json: json support
  • libmapping: the mappings library
  • mobile: android and iOS specific files
  • QArchive: the INScore archive utility
  • Qt: Qt specific sources
  • tests: various utilities for testing specific components
  • view: inscore views implementations
    • HTMLView: used by the WASM library
    • QtView: used by the inscore viewer
    • TextView: (obsolete)
    • VoidView: no view (may be used for memory leak detection on model side)

INScore architecture

INScore is based on a MVC architecture:

  • objects of the model are located in the inscore/model folder
  • objects of the view are located in the view folder. Basis of the view are in inscore/view.

Update of the model and propagation to the view is in charge of the inscore/controller/IGlue object. It is processed by a time task that runs by default every 10 ms.

INScore messages are implemented in inscore/controller, the parser is located in inscore/ITLParser. Incoming messages are pushed on a stack to be processed asynchronously by the time task. Messages are distributed to objects according to their OSC address. Objects of the model are represented as a tree that reflects the OSC address space.

Coding rules

  • class names: use the upper camel case convention
  • method names: use the lower camel case convention
  • fields names: must start with f and use next the camel case convention
  • constants: must start with k and use next the camel case convention

Recommendations

  • Expose class fields and methods only when necessary. The public section of a class should reflect it's services only and not it's internal implementation. The protected section should reflect behaviors shared at inheritance level only. And otherwise, make everything private as much as possible.
  • Don't use the friend attribute
  • Use and abuse of the const keyword whenever possible.