If you're working on a package that other people are working on / are using, please try to stick to the following guidelines:

• Always use the GIT version control system when developing
• One commit per feature with a meaningful commit message
• Use square brackets to annotate for which package the commit is. E.g.: “[btr] new feature for btr package”
• Send a pull request through GitHub, when:
  • you want somebody to review your code
  • you want your code to be tested on a different machine than yours
• When sending pull requests always try to include a person who you'd like to review it in the comment to the request

If you want to introduce major interface changes through you code, make an announcement on the cram-developers mailing list

package.xml

Relevant documentation: Package.xml Ref

• As a <build_depend> only specify all the rosdep keys or ROS packages that your package requires at build-time, e.g. other ROS package sources, library headers. Whereas, <run_depend> is for rosdep keys and ROS packages that your package needs at run-time, e.g. shared libraries, executables, Python modules, launch scripts. More documentation for this can be found here.
• Use <export><deprecated /></export> to tag deprecated packages
• The license for all CRAM code should be BSD / Public Domain
• Put links to github into the <url type=“bugtracker”> and <url type=“repository”> tags

my-package-name.asd files

• Put it into the root of your source directory, no need for symbolic links and asdf directories
• Always explicitly specify dependencies on all the Lisp packages, symbols of which you use in your code (even if the dependency is transitive and is automatically added by other packages that you depend on).

Lisp

• Pay attention to the indentation!!!
• Try not to exceed 80 symbols in width in your code
• Lisp names (variables, classes, methods, packages) are all lowercase with dashes in between: my-awesome-lisp-variable
• Do you usually get that feeling that something is underdocumented? :) Think about that when writing your own code. (not that the author of this guideline always sticks to this particular rule, unfortunately…)
• Try not to use too many packages in your package.lisp. Instead, specify package namespaces explicitly in your code, e.g. cl-transforms:x instead of x. That way code is more readable.
• Don't use cl-tf if you actually want cl-transforms. The difference is:
  • cl-transforms defines datatypes such as pose and transform and their utility functions, such as angle-between-quaternions.
  • cl-transforms-stamped defines datatypes of pose-stamped and transforms-stamped. So once you need a frame header, use cl-transforms-stamped.
  • cl-tf defines the transform listener library, so if you need to do lookup-transform, use cl-tf.
  • cl-tf2 is the equivalent of cl-tf only with an alternative implementation based on the buffer_server from tf2_ros package.

Ros-related

• ROS packages' names are usually lowercase with underscores in between: my_awesome_ros_package.

CRAM is open source software licensed under the BSD licence. This means the code can be used by any third party without having to contribute anything back and having to mention the original authors. Our copyright notice is there to allow others to use our software without being afraid of being sued.

An example copyright notice can be found in the header of most *.lisp files in CRAM.

Here are some guidelines on how to deal with the copyright notice of your code:

• When you create a new *.lisp or *.asd file or any other source code file, please add a copyright notice with your name and institution name.
• If you simply copy pasted a file, please keep the original notice intact.
• For non-sourcecode files such as a package.xml file, make sure to simply put your name in the correct tag (e.g. <author>).
• When editing an existing file, you can add your name into the header if you made a substantial contribution to the code.

A contribution is considered substantial if:

• you added a new feature,
• you fixed a major bug and thereby edited many lines of code in the file,
• you made a major refactoring of the code and improved readability and maintainability greatly.

A contribution is considered not substantial if:

• you fixed a typo,
• fixed indentation,
• slightly improved a documentation string,
• other minor contributions such as minor refactoring and nicification,
• minor bug fixes,
• copy paste of existing code with minor tweaks.

This definition is, of course, not quantitative. If you are unsure, ask the current main maintainer of the software for an advice or look on the Internet for some inspiration, e.g., from the GNU project.

Testing your code is essential! CRAM is a huge framework with a thousands of lines of code, so we have to make sure that whatever bricks we put in our CRAM skyscraper, they are robust. A couple of fragile bricks and our whole building will collapse.

To aid with testing, consider adding unit tests to functions in your code that have math and to your main API functions. Take a look at the testing tutorial to get started on writing tests.

Todo: Some Lisp patterns and stuff would be nice, like tail recursive functions and optimization flags, making sure the functions have no side effects, etcetc…