Cogniteam/CodeConvention - Revision history

Blackpc at 13:04, 31 December 2019

2019-12-31T13:04:50Z

Blackpc at 13:03, 31 December 2019

2019-12-31T13:03:38Z

Blackpc at 12:50, 31 December 2019

2019-12-31T12:50:37Z

Blackpc at 11:02, 31 December 2019

2019-12-31T11:02:25Z

Blackpc at 11:01, 31 December 2019

2019-12-31T11:01:30Z

Blackpc at 21:58, 30 December 2019

2019-12-30T21:58:34Z

Blackpc at 21:54, 30 December 2019

2019-12-30T21:54:06Z

Blackpc at 21:52, 30 December 2019

2019-12-30T21:52:48Z

Blackpc at 17:43, 30 December 2019

2019-12-30T17:43:40Z

Blackpc at 17:37, 30 December 2019

2019-12-30T17:37:15Z

@@ Line 1: / Line 1: @@
 ==Git==
 * Learn basic Git functionality, you must fully understand the following features:
 ** [https://www.atlassian.com/git/tutorials/merging-vs-rebasing Merge vs. Rebase]
 ** [https://www.atlassian.com/git/tutorials/syncing Remote: push, pull]

@@ Line 1: / Line 1: @@
 ==Git==
 * We use [https://datasift.github.io/gitflow/IntroducingGitFlow.html git flow] as out branching strategy
 ===Git Flow===
-* '''develop''' branch must be always in working state
+* Read [https://datasift.github.io/gitflow/IntroducingGitFlow.html this] first if you are not familiar with git flow.
-* '''master''' branch holds only stable releases
+* Main rules:
 ====Feature branches====
 All development is made in feature branches, you can make any commit to this branch.

@@ Line 2: / Line 2: @@
 * We use [https://datasift.github.io/gitflow/IntroducingGitFlow.html git flow] as out branching strategy
 ===Git Flow===
-# '''develop''' branch must be always in working state
+* '''develop''' branch must be always in working state
-# All feature branches should be branched from the latest '''develop''' branch and have the format '''feature/[ISSUE-REF]-[FEATURE-NAME]'''.
+* '''master''' branch holds only stable releases
-# After all features have been integrated and version is ready to be realeased - create a release branch for it from latest '''develop''' branch. Name it with a '''release/v''' prefix, for example '''release/v1.0.0''' or '''release/v0.9.9-rc'''
+====Feature branches====
-# When in release branch, test your version in production environment, only bugfixes are allowed to be commited in release branch. After finishing all tests, update '''VERSION''' file
+All development is made in feature branches, you can make any commit to this branch.
-# The code in the release branch is deployed onto a suitable test environment, tested, and any problems are fixed directly in the release branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until you are happy that the release is good enough to release to customers.
+Ideally, each feature should be related to an issue in GitLab.
 ===Commits===
-* Commit text should be short and precise,
+* Use lower case in commit message (except type/file names and first commit message - 'Initial commit')
 * Don't commit meaningless messages like:
-** ''tiny fixes''
+** <code>tiny fixes</code>
-** ''fix''
+** <code>fix</code>
-** ''crashing''
+** <code>crashing</code>
 ===Naming convention===

@@ Line 44: / Line 44: @@
 | Nodes || Lower camel case<br />Add '_node' suffix ||  '''hamster_driver_node'''<br />'''cognitao_server_node'''<br />'''hector_mapping_node'''
 |-
-| Packages || Lower camel case ||  '''hamster_driver'''<br />'''mafat_planner_ros'''<br />'''cognitao_msgs'''
+| Packages || Lower camel case ||  '''hamster_driver'''<br />'''demo_planner_ros'''<br />'''cognitao_msgs'''
 |-
 | Messages (actions, services and messages) || Upper camel case ||  '''Vector.msg'''<br />'''RunPlan.action'''<br />'''GetMap.srv'''
@@ Line 196: / Line 196: @@
 | Folders || Lower snake case ||  '''cognitao_ros'''<br />'''include/agent_controller'''<br />'''src/map_filters'''
 |-
-| Packages (pure cmake, ROS/ROS2 packages) || Lower camel case ||  '''hamster_driver'''<br />'''mafat_planner'''<br />'''cognitao'''
+| Packages (pure cmake, ROS/ROS2 packages) || Lower camel case ||  '''hamster_driver'''<br />'''demo_planner'''<br />'''cognitao'''
 |}

@@ Line 1: / Line 1: @@
 ==Git==
-TBD
+* We use [https://datasift.github.io/gitflow/IntroducingGitFlow.html git flow] as out branching strategy
 ===Git Flow===
-TBD
+# '''develop''' branch must be always in working state
 ===Commits===
-TBD
+* Commit text should be short and precise,
 ==ROS/ROS2==

@@ Line 48: / Line 48: @@
 ===Object-Oriented Programming===
-* Don't invent wheels - use best practices of object oriented programming and design patterns
+* Don't reinvent wheels - use best practices of object oriented programming and design patterns
 * Make sure your are familiar with basic OOP principles (Inheritance, SRP, SOC, encapsulation, DI, etc...)
 ** [https://en.wikipedia.org/wiki/Object-oriented_programming Object-Oriented Programming]

@@ Line 17: / Line 17: @@
 ! Component !! Convention !! Example
 |-
-| Nodes || Lower camel case ||  '''hamster_driver_node'''<br />'''cognitao_server_node'''<br />'''hector_mapping_node'''
+| Nodes || Lower camel case<br />Add '_node' suffix ||  '''hamster_driver_node'''<br />'''cognitao_server_node'''<br />'''hector_mapping_node'''
 |-
 | Packages || Lower camel case ||  '''hamster_driver'''<br />'''mafat_planner_ros'''<br />'''cognitao_msgs'''

@@ Line 9: / Line 9: @@
 * If your project contains custom messages/services/actions, consider creating separate package '''projectname_msgs''' containing all messages/services/actions, don't put code in this package
-* Create separate package for complex projects comprising many packages: '''projectname_launch'', again, don't put code files here, it used for storing launch files/scripts and parameters/configuration files (see ''hamster_launch'', ''lynx_launch'')
+* Create separate package for complex projects comprising many packages: '''projectname_launch''', again, don't put code files here, it used for storing launch files/scripts and parameters/configuration files (see ''hamster_launch'', ''lynx_launch'')
 ===Files and folders===
@@ Line 41: / Line 41: @@
 ** '''Icp2dMapAligner''' ''instead of'' MapAligner
 ** '''VoxelGridMap''' ''instead of'' Map3d
 ===Object-Oriented Programming===
@@ Line 168: / Line 171: @@
 | Packages (pure cmake, ROS/ROS2 packages) || Lower camel case ||  '''hamster_driver'''<br />'''mafat_planner'''<br />'''cognitao'''
 |}
 === Class template ===

@@ Line 1: / Line 1: @@
-==Code style and Naming conventions==
+==ROS/ROS2==
 * Use C++14 standard  <syntaxhighlight lang="cmake">
 # CMake
@@ Line 36: / Line 57: @@
 ** [https://www.journaldev.com/31902/gangs-of-four-gof-design-patterns Design Patterns by Gang Of Four] '''MUST READ'''
-===Conventions names examples===
+===Convention names description===
 {| class="wikitable" style="text-align: center; width: 100%; padding: 10px;"
 ! Upper Camel Case !! Lower Camel Case !! Upper Snake Case !! Lower Snake Case
@@ Line 43: / Line 64: @@
 |}
-===C++ naming conventions===
+===Naming conventions===
 {| class="wikitable" style="width: 100%"
 |-
@@ Line 146: / Line 167: @@
 |-
 | Packages (pure cmake, ROS/ROS2 packages) || Lower camel case ||  '''hamster_driver'''<br />'''mafat_planner'''<br />'''cognitao'''
 |}
@@ Line 157: / Line 176: @@
 * [https://git.cogni.io/maytronics/maytronics/snippets/8 Try to debug this]
-=== Read more ===
+=== Class template ===
-== C++ class template ==
+==== Header file ====
 <syntaxhighlight lang="C++">
@@ Line 420: / Line 434: @@
 </syntaxhighlight>
-=== Source file ===
+==== Source file ====
 <syntaxhighlight lang="C++">
@@ Line 534: / Line 548: @@
                                                                    // new line
 </syntaxhighlight>