From 8e11768a514eb5ac21f49e61ca316751844d1184 Mon Sep 17 00:00:00 2001 From: Brendan Le Foll Date: Tue, 4 Nov 2014 23:41:46 +0000 Subject: [PATCH] naming.md: update documentation for naming Signed-off-by: Brendan Le Foll --- docs/naming.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/docs/naming.md b/docs/naming.md index a8b3bfca..68569ddd 100644 --- a/docs/naming.md +++ b/docs/naming.md @@ -2,20 +2,25 @@ Naming a module {#naming} =============== UPM attemps to follow a clear naming pattern. Modules should be sensibly named -and then placed in /usr/lib/upm and headers in /usr/include/upm. +and then placed in ${libdir}/upm and headers in ${includedir}/upm, all modules +should be prefixed with libupm-. The upm_module_init will +automatically name python UPM modules as pyupm_ and javascript +modules as jsupm_. For example for src/grove/ the library built +will be libupm-grove.so, the python module pyupm_grove and the js module +jsupm_grove. -### Choosing a name +### Choosing a name for a new module -1. Pick a name -2. Use it +1. Pick a name, typically the chip name is the most sensible +2. Use it & stick to it ### Rules for name picking -1. Your lib must belong to namespace UPM -2. Usually picking the name of the chip of your sensor/actuator might make -sense. Other times this does not. Try to pick a generic name so people with a -similar sensor can inherit your class if they only have minor changes. -3. Avoid brand names +1. Your lib must belong to the UPM namespace +2. Usually picking the name of the chip of your sensor/actuator makes sense. +Other times this does not. Try to pick a generic name so people with a similar +sensor can inherit your class if they only have minor changes. +3. Avoid brand names, often your module can be very generic with little effort ### Doubt