The aRts Handbook
Prev | Chapter 10. Contributing to aRts | Next

# 10.3. Coding Standards

For getting a consistent reading through all the sources, it is important to keep the coding style the same, all over the aRts source. Please, even if you just write a module, try to write/format your source accordingly, as it will make it easier for different people to maintain the source tree, and easier to copy pieces of from one source to another.

Naming of member functions

  QT/Java style, that means capitalization on word breaks, and first letter always without capitalization; no underscores.

  This means for instance

         1    createStructureDesc()
         2    updateWidget();
         3    start();

Class members

  Class members are not capitalized, such as menubar or button.

  When there are accessing functions, the standard should be the MCOP way, that is, when having an long member foo, which shouldn't be visible directly, you create

         1    foo(long new_value);
         2    long foo();

  functions to get and set the value. In that case, the real value of foo should be stored in _foo.

Class names

  All classes should be wordwise capitalized, that means ModuleView, SynthModule. All classes that belong to the libraries should use the Arts namespace, like Arts::Soundserver.

  The implementations of MCOP classes should get called Class_impl, such as SoundServer_impl.

Parameters

  Parameters are always uncapitalized.

Local variables

  Local variables are always uncapitalized, and may have names like i, p, x, etc. where appropriate.

Tab width (Shift width)

  One tab is as long as 4 spaces.

Naming of source files

  Source files should have no capitalization in the name. They should have the name of the class when they implement a single class. Their extension is .cc if they refer to Qt/GUI independant code, and .cpp if they refer to Qt/GUI dependant code. Implementation files for interfaces should be called `foo`_impl, if Foo was the name of the interface.

  IDL files should be called in a descriptive way for the collection of interfaces they contain, also all lower case. Especially it is not good to call an idl file like the class itself, as the .mcopclass trader and type info entries will collide, then.

Prev | Home | Next
Mailing Lists | Up | Future Work