Home > On-Demand Archives > Talks >
Embedded Software Programming Rules, Tips and Tricks
Jean Labrosse - Watch Now - Duration: 28:53
Thank you for your kind words.
Thanks for your insights. I particularly liked the Global/extern tips/trick
You are welcomed.
Why is it that you advise against macros that invoke other macros? What are some downsides that you see in this practice? I've long used macros that invoke other macros for the purposes of abstracting mathematical operations (i.e #define TIMER_TICKS_PER_MSEC (TIMER_TICKS_PER_SEC / 1000) ), and have found the practice highly beneficial. Might there be some situations where it is a good idea to implement macros which invoke other macros? What is a situation or example where it is a bad idea to implement a macro which invokes other macros?
Well, I dont have an issue when a macro (code) includes another macro (constant). I have an issue when a code macro includes another code macro and worse yet, when that invokes another code macro!
Also, Iève seen a macro that was 30+ lines of code and included local labels and gotos.
I prefer using inline functions to complex code macros.
Hi Jean, thanks for the great talk. I have a question about Rule #8 on slide 14. In that part of the presentation you were advocating for adding extra spaces to make the code line up. I agree that it does make the code easier to read, but in my experience it also makes it harder (more time) to maintain. Do you have any thoughts on that balance, particularly as it pertains to this rule? Thanks.
Scott, thanks for your question. Well, I realize that it's harder to maintain but for me, it's worth the effort. Also, some editor have 'column mode' where you can highlight a column of text and add spaces in that column or delete spaces. That's a feature I requested to be added in IAR's Embedded Workbench (which they did) and it makes life so much easier to shift left or right columns. I used to use CodeRight years ago which had that feature. I'm sure other editors have it too.
Hi Jean, like always a great talk. Those great and practical insights help a lot for clean code. Thanks a lot!
Thank you Thomas.
Clear and straightforward talk! Thank you!
Thank you, I'm glad you liked it.
It's always a pleasure reading the uC/OS-III code when debugging. The API is very consistent. Did you format the code and the function header comments all by hand throughout, or use a tool to enforce it? I find even when we have a coding standard, everyone's style is still ever so slightly different.
Thanks for the kind words. All formatted by hand. There was nothing at the time that I was satisfied with to do it automatically.
It’s a great RTOS that I enjoy working with in my day job. I get the feeling that it’s a much less popular choice nowadays. I tried uC/FS with it (mainly because of the wear levelling), but struggled with it. So if you’re looking for inspiration for next year’s talks, anything Micrium-related would be good!
This video contains precious pearls: it's a clear explanation of good software practices. Thanks a lot for your work and passion!