| title | Hacking Tips |
|---|---|
| order | 3 |
A quick index of useful concepts for would-be contributors (and myself every few months).
Set yourself up so you can look up and jump to/from functions/symbols inside your text editor or IDE. This is my personal setup with vim.
Then start looking at the example code and related comments in the test dir; you'll be able to jump to function definitions/implementations and read their documentation in context with the usage in the test.
Communication is always welcome, feel free to send a pull request or drop me a line at sirio.bm@gmail.com.
-
Use clang-format, see .clang-format for formatting info.
-
All hail the Linux kernel coding style
- tabs!
-
Keep things clean by prefixing function groups with 4-letter faux-namespaces.
Example set of functions for a fictional library:
/* usls = the Useless Library */ void *usls_new(); int usls_do(void *usls); void usls_free(void *usls);
-
Handle end-of-function cleanup with GOTOs:
- when in doubt, have a function return a status code as
int:0 == success - when allocating, return a pointer:
NULL == fail - when calling libc, probably best to return an FD:
-1 == fail
- when in doubt, have a function return a status code as
-
Believe in the 80-character margin. Ignore it when it makes the code clearer.
-
Eschew the '_l' suffix convention found in
libcand other places. Rather, explicitly suffix functions with '32' or '64' when multiple word lengths are being used. -
Visibility is important: https://gcc.gnu.org/wiki/Visibility.
See the relevant helper macros in nonlibc.h
-
Use test programs to show intended usage.
-
Header files should list functions in the order in which they appear in the corresponding
.cfile. -
Use more thoughtful
<stdint.h>and<inttypes.h>types to declare and print variables in this library (portability).