add todo.md

readme.md

@@ -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 ###

todo.md

@@ -0,0 +1,5 @@
+# TODO #
+
+- [ ] display SHA commit on demo
+- [ ] guideline for create a new issue
+- [ ] make some doxygen documentation