Difference between revisions of "LibreCAD 3 - LibreCAD 3 - code style"

From LibreCAD wiki
Jump to: navigation, search
(Code style guide)
(Code style guide)
Line 16: Line 16:
 
example:
 
example:
 
<pre>
 
<pre>
Circle::Circle(const Coordinate& center, double radius) : _center(center), _radius(radius) {
+
Circle::Circle(Coordinate const& center, double radius) : _center(center), _radius(radius) {
 
     if (_radius < 0.0) {
 
     if (_radius < 0.0) {
 
         throw "Invalid radius";
 
         throw "Invalid radius";
Line 57: Line 57:
 
Good:
 
Good:
 
<pre>
 
<pre>
Line::Line(const geo::Coordinate& start, const geo::Coordinate& end, const Layer_SPtr 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) {..}
 
</pre>
 
</pre>
  
 
Bad:
 
Bad:
 
<pre>
 
<pre>
Line::Line(const geo::Coordinate& start, const geo::Coordinate& end, const Layer_SPtr &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) {..}
 
</pre>
 
</pre>
  
Line 89: Line 89:
 
Good:
 
Good:
 
<pre>
 
<pre>
Line::Line(const geo::Coordinate& start, const geo::Coordinate& 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) {..}
 
</pre>
 
</pre>
  
Line 97: Line 97:
 
</pre>
 
</pre>
  
'''Use Camel case'''
+
'''Use Camel case '''
 
Try to use camel case as much as possible
 
Try to use camel case as much as possible
  

Revision as of 14:29, 18 January 2015

Code style guide

Accessor naming:

use foo->layer()

instead of

 foo->getLayer();


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

example:

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

Exceptions:

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:

Good:

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

Bad:

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) {..}

Bad:

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.

Good:

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

Bad:

  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