We have moved to https://dokuwiki.librecad.org/

Lots of content was already moved to the new wiki, but there is still work to do. If you want to contribute, please register a new account at https://dokuwiki.librecad.org/

This wiki will be kept for a while to keep search engine results valid. Moved sites may be deleted here in future.

LibreCAD 3 - LibreCAD 3 - code style

From LibreCAD wiki
Revision as of 14:29, 18 January 2015 by R. van Twisk (Talk | contribs)

Jump to: navigation, search

Code style guide

Accessor naming:

use foo->layer()

instead of


Immutables: Are immutables must be created 'valid', throw an exception if a immutable is attempted to be created that is invalid.


Circle::Circle(Coordinate const& center, double radius) : _center(center), _radius(radius) {
    if (_radius < 0.0) {
        throw "Invalid radius";

All variables in a immutable class must be declared as const


Only throw exceptions in rare situations that are effectively unreasonable.

For example:

document->entityByID(...); // return null if a entry does not exists

hide shared_ptr behind a typedef:

    typedef std::shared_ptr<Circle> Circle_SPtr;
    typedef std::shared_ptr<const Circle> Circle_CSPtr;

This so we can 'shorten' our shred pointers, example:

  std::list<std::shared_ptr<const Circle>> myListLong; // Less readble
  std::list<Circle_CSPtr> myListReadable; // better readable

Shared pointer passing:

never pass shared_ptr by reference:


Line::Line(geo::Coordinate const& start, geo::Coordinate const& end, Layer_SPtr const  layer) : CADEntity(layer), Vector(start, end) {..}


Line::Line(geo::Coordinate const& start, geo::Coordinate const& end, Layer_SPtr const &layer) : CADEntity(layer), Vector(start, end) {..}

using namespace std;

Don't bring in the std namespace into global. So always use std::vector, std::map, std::string etc...

Variable declarations on separate lines

For readability we prefer to have variables declared on separate lines. This will make commenting on variables when needed easer and in general add to readability.

good style:

const Coordinate _extensionPoint1;
const Coordinate _extensionPoint2;

bad style:

const Coordinate _extension_point1, _extension_point2;

Const variables Const modifier must be added after the variable type: Good:

Line::Line(geo::Coordinate const& start, geo::Coordinate const& end, const Layer_SPtr layer) : CADEntity(layer), Vector(start, end) {..}


Line::Line(geo::Coordinate const & start, geo::Coordinate const & end, const Layer_SPtr &layer) : CADEntity(layer), Vector(start, end) {..}

Use Camel case Try to use camel case as much as possible

Some exceptions:

  • Variable names in a class can start with a underscore
  • add a _ (underscore) if the variable name get's unreadable, for example this is ok Dimension_CSptr
  • Function names to add clarification for example on_dimRadial_changed. where 'on' and 'changed' are not part of the variable name dimRadial but they are there to notify something.


  const String _textValue;
  void on_dimRadial_change() {...};


  const String _text_value;
  void on_dim_radial_change() {...};

Class name's always start with a upper case letter

Variable name's always starts with a lower case letter