polarlightning wrote on Tuesday, January 17, 2012:
I am currently selecting the RTOS for our next products. When looking at FreeRTOS for the first time, the first thing that tells me something is not as well as it could be is the naming conventions used in FreeRTOS. Literals having sequences of lower case characters followed by a sequence of upper case characters is - well, to speak frankly - ugly to my mind . Hierarchical names and some more common naming convention would be better. I suggest that ALL literals and functions names should start with FREERTOS_ or FRTOS_ (literals) or FreeRTOS (functions and variables) even though this “return type encoding in names” would be applied. Now at first sight the lack of logic and making these identifiers not easily recognazible from own or third vendor codes is a little “threat” or big inconvinience. When looking and the available ports and documentation otherwise this looks very promising. If you want just one example of consistent naming, you might take a look at Micrium’s uC/OS-II (commercial). I think it might not even be a big task to use some template engine to rename everything. Of course this can be done locally, but it is not as good as having the original code look very logical and very well named.
Good convention to stand out FreeRTOS-related stuff in project suggestion:
- FRTOS_<MODULE>_<ITEM> for literals and
- FRTOS<MODULE><Verb><Subject> for function, variables, types (applied suitably for each)
Examples:
#define FRTOS_QUEUE_TYPE_BASE (now: queueQUEUE_TYPE_BASE)
xFRTOSQueueAltGenericSend (now: xQueueAltGenericSend)
vFRTOSTaskSuspend (now: vTaskSuspend)