|
|
@@ -61,7 +61,6 @@ C is a dangerous language by itself, plus tinyusb make use of goodies features o
|
|
|
- [MISRA-C](http://www.misra-c.com/Activities/MISRAC/tabid/160/Default.aspx)
|
|
|
- [Power of 10](http://spinroot.com/p10/)
|
|
|
- [Jet Propulsion Laboratory (JPL) for C](http://lars-lab.jpl.nasa.gov)
|
|
|
-- ...
|
|
|
|
|
|
Where is possible, standards are followed but it is almost impossible to follow all of these without making some exceptions. I am pretty sure this code base violates more than what are described below, if you can find any, please report it to me or file an issue on github.
|
|
|
|
|
|
@@ -88,19 +87,26 @@ one of my favorite rule
|
|
|
3. *`Do not use dynamic memory allocation after initialization`*
|
|
|
the tinyusb uses the static memory for all of its data.
|
|
|
|
|
|
-4. **`Limit functions to no more than 60 lines of text`** 60 is a little bit too strict, I will update the relaxing number later
|
|
|
+4. **`Limit functions to no more than 60 lines of text`**
|
|
|
+60 is a little bit too strict, I will update the relaxing number later
|
|
|
|
|
|
-5. *`Use minimally two assertions per function on average`* not sure the exact number, but I use a tons of those assert
|
|
|
+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
|
|
|
+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.
|
|
|
+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.
|
|
|
+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.
|
|
|
+10. *`Compile with all warnings enabled, and use one or more source code analyzers`*
|
|
|
+I try to use all the defensive options 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
|
|
|
|
|
|
### JPL ###
|
hathach