Some coding style cleanup.

This commit is contained in:
Jim Evins
2017-01-14 01:04:35 -05:00
parent f6de611a68
commit da3436a02a
5 changed files with 62 additions and 45 deletions
+47 -30
View File
@@ -1,28 +1,31 @@
Glabels Coding Style Glabels Coding Style
==================== ====================
This file describes the coding style used in all glabels source code. Any patches or pull requests should This file describes the coding style used in all glabels source code. Any
adhere to this style. patches or pull requests should adhere to this style.
Tabs vs. Spaces Formatting
--------------- ----------
Tabs are only used at the beginning of a line, and only used to express indentation level. Spaces are used ### Tabs vs. Spaces
for any other type of vertical alignment, e.g. aligning function arguments. This ensures that the code
displays correctly everywhere, regardless of the viewer's tab size, and does not inflict the viewer with my
choice of tab size (8 spaces).
I use the emacs smart-tabs-mode to automatically enforce this. Tabs are only used at the beginning of a line, and only used to express
See https://www.emacswiki.org/emacs/SmartTabs for more information. indentation level. Spaces are used for any other type of vertical alignment,
e.g. aligning function arguments. This ensures that the code displays
correctly everywhere, regardless of the viewer's tab size, and does not inflict
the viewer with my choice of tab size (8 spaces).
I use the emacs smart-tabs-mode to automatically enforce this. See
https://www.emacswiki.org/emacs/SmartTabs for more information.
Indentation Style ### Indentation Style
-----------------
Glabels code uses the Allman style (a.k.a "BSD Style") of code indentation. I.e. the brace associated with a Glabels code uses the Allman style (a.k.a "BSD Style") of code indentation.
control statement is placed on the next line, indented to the same level as the control statement. I.e. the brace associated with a control statement is placed on the next line,
Statements within the braces are indented to the next level. indented to the same level as the control statement. Statements within the
braces are indented to the next level.
``` ```
while ( condition ) while ( condition )
@@ -41,24 +44,34 @@ else
} }
``` ```
Also applies to class and namespace declaration statements. Also applies to function, class and namespace declaration statements.
See https://en.wikipedia.org/wiki/Indent_style#Allman_style for more information. See https://en.wikipedia.org/wiki/Indent_style#Allman_style for more
information.
### Parenthesis
- Never place spaces between a function name and its opening paren.
- Always place a space between a control statement and its opening paren.
- Never use parens in return statements when not necessary.
File Organization File Organization
----------------- -----------------
Generally code is organized into modules. Usually a module defines a single class or a small namespace of Generally code is organized into modules. Usually a module defines a single
functions/constants/etc. A module is defined by two files: a header file (its specification) and an class or a small namespace of functions/constants/etc. A module is defined by
implementation file. Header filenames have a ".h" extension and implementation filenames have a ".cpp" two files: a header file (its specification) and an implementation file.
extension. Header filenames have a ".h" extension and implementation filenames have a
".cpp" extension.
### Self-contained Headers ### Self-contained Headers
Header files should be self-contained. I.e. they should not require any prerequisite includes. To enforce Header files should be self-contained. I.e. they should not require any
this requirement, an implementation file shall include its header file before any other includes. prerequisite includes. To enforce this requirement, an implementation file
shall include its header file before any other includes.
### Multiple Inclusion Guards ### Multiple Inclusion Guards
@@ -79,18 +92,22 @@ All header files should have an ifndef guard to prevent multiple inclusion.
Header files should be included in the following order. Header files should be included in the following order.
1. header file for this module (e.g. this would be "Foo.h" in "Foo.cpp"). 1. header file for this module (e.g. this would be "Foo.h" in "Foo.cpp").
2. C system header files (preference is for the C++ version if available, e.g. <cmath> instead of <math.h>. 2. C system header files (preference is for the C++ version if available,
e.g. <cmath> instead of <math.h>.
3. C++ system header files (e.g. STL files) 3. C++ system header files (e.g. STL files)
4. Qt header files 4. Qt header files
5. Other libraries' header files 5. Other libraries' header files
6. Other glabels header files. 6. Other glabels header files.
Paths used in include directives should always be relative to either the glabels source directory or an Paths used in include directives should always be relative to either the
appropriate base directory for each library. They should NEVER include UNIX directory shortcuts such as "." glabels source directory or an appropriate base directory for each library.
(the current directory) or ".." (the parent directory). They should NEVER include UNIX directory shortcuts such as "." (the current
directory) or ".." (the parent directory).
Angle brackets ("<>") should be used for inclusion of all external header files (such as C/C++ and Qt Angle brackets ("<>") should be used for inclusion of all external header files
header files). Double quotes should be used for all glabels header files. (such as C/C++ and Qt header files). Double quotes should be used for all
glabels header files.
Do not use forward declarations to any external entities. Use the appropriate include directive instead. Do not use forward declarations to any external entities. Use the appropriate
include directives instead.
+4 -4
View File
@@ -78,9 +78,9 @@ ColorNode::ColorNode( const QString& key )
/// ///
bool ColorNode::operator==( const ColorNode& cn ) bool ColorNode::operator==( const ColorNode& cn )
{ {
return ( (mIsField == cn.mIsField) && return (mIsField == cn.mIsField) &&
(mColor == cn.mColor) && (mColor == cn.mColor) &&
(mKey == cn.mKey) ); (mKey == cn.mKey);
} }
@@ -89,9 +89,9 @@ bool ColorNode::operator==( const ColorNode& cn )
/// ///
bool ColorNode::operator!=( const ColorNode& cn ) bool ColorNode::operator!=( const ColorNode& cn )
{ {
return ( (mIsField != cn.mIsField) || return (mIsField != cn.mIsField) ||
(mColor != cn.mColor) || (mColor != cn.mColor) ||
(mKey != cn.mKey) ); (mKey != cn.mKey);
} }
+2 -2
View File
@@ -262,7 +262,7 @@ LabelEditor::zoomToFit()
bool bool
LabelEditor::isZoomMax() const LabelEditor::isZoomMax() const
{ {
return ( mZoom >= zoomLevels[0] ); return mZoom >= zoomLevels[0];
} }
@@ -272,7 +272,7 @@ LabelEditor::isZoomMax() const
bool bool
LabelEditor::isZoomMin() const LabelEditor::isZoomMin() const
{ {
return ( mZoom <= zoomLevels[nZoomLevels-1] ); return mZoom <= zoomLevels[nZoomLevels-1];
} }
+1 -1
View File
@@ -558,7 +558,7 @@ bool LabelModel::isSelectionAtomic()
} }
} }
return (nSelected == 1); return nSelected == 1;
} }
+5 -5
View File
@@ -44,8 +44,8 @@ TextNode::TextNode( bool isField, const QString &data )
/// ///
bool TextNode::operator==( const TextNode& other ) bool TextNode::operator==( const TextNode& other )
{ {
return ( (mIsField == other.mIsField) && return (mIsField == other.mIsField) &&
(mData == other.mData) ); (mData == other.mData);
} }
@@ -54,8 +54,8 @@ bool TextNode::operator==( const TextNode& other )
/// ///
bool TextNode::operator!=( const TextNode& other ) bool TextNode::operator!=( const TextNode& other )
{ {
return ( (mIsField != other.mIsField) || return (mIsField != other.mIsField) ||
(mData != other.mData) ); (mData != other.mData);
} }
@@ -134,7 +134,7 @@ bool TextNode::isEmptyField( merge::Record* record ) const
{ {
if ( record->contains( mData ) ) if ( record->contains( mData ) )
{ {
return ( (*record)[mData].isEmpty() ); return (*record)[mData].isEmpty();
} }
} }