diff options
| author | hathach <[email protected]> | 2013-05-08 12:29:08 +0700 |
|---|---|---|
| committer | hathach <[email protected]> | 2013-05-08 12:29:08 +0700 |
| commit | 2bbb9f2c6b3aec03b47a2c38c8f2d5bd078143d7 (patch) | |
| tree | 885ed1cd571e4a1b3dc60f88bbcf5aa2e90612c8 | |
| parent | 0e65ce62afe05e6ae04cb13fad5e853d0b9cee44 (diff) | |
test markdown
| -rw-r--r-- | readme.md | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -87,7 +87,7 @@ the tinyusb uses the static memory for all of its data. 5. **Use minimally two assertions per function on average:** not sure the exact number, but I use a tons of those assert 6. **Declare data objects at the smallest possible level of scope:** one of the best & easiest rule to follow 7. **Check the return value of non-void functions, and check the validity of function parameters:** I did check all of the public application API's parameters. For internal API, calling function needs to trust their caller to reduce duplicated check. -8. *Limit the use of the preprocessor to file inclusion and simple macros* Although I prefer inline function, however C macros are far powerful than that. I simply cannot hold myself to use, for example X-Macro technique to simplify code. +8. `Limit the use of the preprocessor to file inclusion and simple macros` Although I prefer inline function, however C macros are far powerful than that. I simply cannot hold myself to use, for example X-Macro technique to simplify code. 9. **Limit the use of pointers. Use no more than two levels of dereferencing per expression:** never intend to get in trouble with complex pointer dereferencing. 10. **Compile with all warnings enabled, and use one or more source code analyzers:** I try to use all the defensive option of gnu, let me know if I miss some. > -pedantic -Wextra -Wswitch-default -Wunsafe-loop-optimizations -Wcast-align -Wlogical-op -Wpacked-bitfield-compat -Wpadded -Wnested-externs -Wredundant-decls -Winline -Wpacked |
