no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
Last revision | |||
— | doc:best-practices [2014/12/07 09:33] – created admin | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Best practices ====== | ||
+ | |||
+ | This page is to outline some best practices that have been developed while working with the KnowRob system. It is recommended to follow these guidelines to ensure interoperability and facilitate scaling to larger installations. | ||
+ | |||
+ | |||
+ | ===== Separate code and data ===== | ||
+ | |||
+ | KnowRob packages may contain both code (i.e. Prolog and Java programs) and data (i.e. OWL files). In many cases, the code can be kept rather generic (e.g. methods for reading objects in a map), while the data is inherently specific to the use case at hand. To allow flexible re-use of the system in different settings, try to minimize the amount of data that is auto-loaded when a package is launched. For example, do not auto-load environment maps in the init.pl file, but use a launch file such as the ones in // | ||
+ | |||
+ | |||
+ | ===== Use unique identifiers ===== | ||
+ | |||
+ | Though some old OWL files still contain them, avoid the use of simple instance names such as ' | ||
+ | |||
+ | Instead, use the // | ||
+ | |||
+ | |||
+ | ===== Keep dependency lists small ===== | ||
+ | |||
+ | Especially when combining several packages for a demonstration, | ||
+ | |||
+ | This practice quickly leads to clogged dependency lists that load packages that are only needed in some use cases, but may cause problems in others. Instead, create specific packages for each demo use case that (usually) only consist of launch files, dependencies and an init.pl file that initializes KnowRob. This will make it easy to start KnowRob for your use case, but will not cause problems for anyone else. | ||
+ | |||
+ | |||
+ | ===== Put special-purpose functionality into knowrob_addons ===== | ||
+ | |||
+ | As explained [[/ | ||
+ | |||
+ | |||
+ | ===== Create wiki pages while developing a novel package ===== | ||
+ | |||
+ | To build up documentation while developing a package, it proved useful to simply copy/paste the test queries used for development to a wiki page. Ideally, they should contain all steps needed from a bash shell to a working environment and should be executable one after the other without having to think too much. From our experience, creating this documentation is very little overhead at development time, when these queries and the values to be used are all well-known, while remembering how to use the code and reconstructing the queries later on is often much more difficult. | ||
+ | |||
+ | |||