]>
Commit | Line | Data |
---|---|---|
1 | ------------------------------------------------------------------------------- | |
2 | HACKING | |
3 | ------------------------------------------------------------------------------- | |
4 | ||
5 | Coding style | |
6 | ------------ | |
7 | ||
8 | This project is programmed using the Linux kernel coding style, see | |
9 | http://lxr.linux.no/linux/Documentation/CodingStyle for details. | |
10 | ||
11 | Please use the same style for any code contributions, thanks! | |
12 | ||
13 | The Python decoders should follow the usual Python conventions and use | |
14 | Python idioms as far as it makes sense. The coding style should mostly follow | |
15 | the Python PEP-8, which includes the convention of 4 spaces for indentation. | |
16 | See http://www.python.org/dev/peps/pep-0008/ for details. | |
17 | ||
18 | ||
19 | Contributions | |
20 | ------------- | |
21 | ||
22 | - Patches should be sent to the development mailinglist at | |
23 | sigrok-devel@lists.sourceforge.net (please subscribe to the list first). | |
24 | ||
25 | https://lists.sourceforge.net/lists/listinfo/sigrok-devel | |
26 | ||
27 | - Alternatively, you can also clone the git repository and let us know | |
28 | from where to pull/review your changes. You can use gitorious.org, | |
29 | github.com, or any other public git hosting site. | |
30 | ||
31 | ||
32 | Random notes | |
33 | ------------ | |
34 | ||
35 | - Consistently use g_try_malloc() / g_try_malloc0(). Do not use standard | |
36 | malloc()/calloc() if it can be avoided (sometimes other libs such | |
37 | as libftdi can return malloc()'d memory, for example). | |
38 | ||
39 | - Always properly match allocations with the proper *free() functions. If | |
40 | glib's g_try_malloc()/g_try_malloc0() was used, use g_free() to free the | |
41 | memory. Otherwise use standard free(). Never use the wrong function! | |
42 | ||
43 | - Never use g_malloc() or g_malloc0(). These functions do not return NULL | |
44 | if not enough memory is available but rather lead to an exit() or segfault | |
45 | instead. This behaviour is not acceptable for libraries. | |
46 | Use g_try_malloc()/g_try_malloc0() instead and check the return value. | |
47 | ||
48 | - You should never print any messages (neither to stdout nor stderr nor | |
49 | elsewhere) "manually" via e.g. printf() or g_log() or similar functions. | |
50 | Only srd_err()/srd_warn()/srd_info()/srd_dbg()/srd_spew() should be used. | |
51 | ||
52 | - Use glib's gboolean / TRUE / FALSE for boolean types consistently. | |
53 | Do not use <stdbool.h> and its true / false, and do not invent private | |
54 | definitions for this either. | |
55 | ||
56 | - Consistently use the same naming convention for #include guards in headers: | |
57 | <PROJECTNAME>_<PATH_TO_FILE>_<FILE> | |
58 | This ensures that all #include guards are always unique and consistent. | |
59 | Example: LIBSIGROKDECODE_SIGROKDECODE_INTERNAL_H | |
60 | ||
61 | - Consistently use the same naming convention for API functions: | |
62 | <libprefix>_<groupname>_<action>(). | |
63 | ||
64 | Examples: | |
65 | srd_log_loglevel_set(), srd_log_loglevel_get(), srd_log_handler_set(), | |
66 | srd_log_handler_set_default(), and so on. | |
67 | ||
68 | Getter/setter function names should usually end with "_get" or "_set". | |
69 | Functions creating new "objects" should end with "_new". | |
70 | Functions destroying "objects" should end with "_destroy". | |
71 | Functions adding or removing items (e.g. from lists) should end with | |
72 | either "_add" or "_remove". | |
73 | Functions operating on all items from a list (not on only one of them), | |
74 | should end with "_all", e.g. "_remove_all", "_get_all", and so on. | |
75 | Use "_remove_all" in favor of "_clear" for consistency. | |
76 | ||
77 | - In Doxygen comments, put an empty line between the block of @param lines | |
78 | and the final @return line. The @param lines themselves (if there is more | |
79 | than one) are not separated by empty lines. | |
80 | ||
81 | ||
82 | Protocol decoder guidelines | |
83 | --------------------------- | |
84 | ||
85 | - The 'desc' metadata field for a protocol decoder, which contains a | |
86 | short, one-line description of the protocol/bus, should be at most 55 | |
87 | characters long, and end with a full stop. This short description can be | |
88 | displayed on the command-line using "sigrok-cli -V -l 3", or in various | |
89 | different places in GUIs. | |
90 | ||
91 | - Longer, multi-line descriptions should be placed in the protocol | |
92 | decoder's __init__.py file as docstring. It can be viewed (for a specific | |
93 | protocol decoder, e.g., UART) via "sigrok-cli -a uart", or in various | |
94 | other places in GUIs. | |
95 | ||
96 | - Generally use strings for states (of the PD state machine), not integers. | |
97 | This avoids having to keep a list of state definitions at the top of file. | |
98 | The performance overhead for this is negligible in practice. | |
99 | ||
100 | Recommended: | |
101 | self.state = 'IDLE' | |
102 | self.state = 'GET STOP BIT' | |
103 | Not recommended: | |
104 | self.state = IDLE | |
105 | self.state = GET_STOP_BIT | |
106 | (where IDLE = 0 and GET_STOP_BIT = 1, for example) | |
107 | ||
108 | - Generally use strings for commands/IDs in generated protocol packets. | |
109 | This avoids having to know magic numbers of the PD in higher-level PDs. | |
110 | The performance overhead for this is negligible in practice. | |
111 | ||
112 | Recommended: | |
113 | self.put(x, y, p, ['STOPBIT', 0, 0]) | |
114 | self.put(x, y, p, ['ADDRESS READ', 0x51]) | |
115 | Not recommended: | |
116 | self.put(x, y, p, [STOPBIT, 0, 0]) | |
117 | self.put(x, y, p, [ADDRESS_READ, 0x51]) | |
118 | (with STOPBIT = 3 and ADDRESS_READ = 7, for example) | |
119 | ||
120 | - Use ALL-CAPS names for PD states and protocol packet commands/ID. | |
121 | Words should be separated by spaces (not underscores or the like). | |
122 | ||
123 | Recommended: | |
124 | 'FIND ADDRESS', 'GET TEMPERATURE', 'START' | |
125 | Not recommended: | |
126 | 'FIND_ADDRESS', 'Get Temperature', 'start' | |
127 | ||
128 | ||
129 | Release engineering | |
130 | ------------------- | |
131 | ||
132 | See | |
133 | ||
134 | http://sigrok.org/wiki/Developers/Release_process | |
135 | ||
136 | for a list of items that need to be done when releasing a new tarball. | |
137 |