Home > On-Demand Archives > Q&A Sessions >
Live Q&A - Embedded Software Programming Rules, Tips and Tricks
Jean Labrosse - Watch Now - Duration: 39:10
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!
15:34:49 From Alice : In your documentation slides, you mentioned mind maps. What are mind maps for firmware documentation? 15:37:29 From Alice : Yes, thank you! 15:38:22 From Alice : What was the bug with floating point comparison? You said to always check a range. 15:39:10 From John : You say "never change APIs"... but when does this start? After release to testing? Otherwise during my development I would end up with V1000... 15:40:40 From René Andrés Ayoroa : about the 80 character rule, code reviews are not done in paper anymore right? what are some tools for code review? 15:40:44 From Miguel Angel Moreno : Jean: You were SO RIGHT ON the “80-characters line limit” … 😄 My thought is that the “80-chars” rule comes from the old days of dot-matrix line printers, which had that “hard limitation” when printing … My own choice with modern editors is to use a “120-char” line limit generally … but ignore the limit on valid cases just like the ones you showed (tables, definitions, etc.) 15:41:04 From 주희수 : Reacted to "You say "never chang..." with 😂 15:41:48 From Erwin Pschernig : What do you think of the mechanism other languages like Python or Java use. They mark API's as deprecated and remove/replace them in follow up Releases? 15:42:03 From Jacob Beningo : Reacted to "Jean: You were SO R..." with 👍 15:42:35 From Bob Fish : What's your opinion of scripting languages i.e. python where style is dictated? Comment - One day I'll look at μC/OS source that is often referred to as a 'work of art'! 15:42:56 From Thomas Schaertel : Do you have any recommendation of using Test Driven Design for RTOS based applications? 15:43:13 From Miguel Angel Moreno : Replying to "What was the bug wit..." There is no such a “bug” … It is the implicit imprecision of Base-2 floating point math versus the human Base-10 math … When you deal with floating point variables, you ALWAYS run the risk of not “matching an equality” as you meant it to be in your code … 15:46:47 From Alice : Reacted to "There is no such a ..." with 👍 15:47:16 From John : For autonomous systems which run unattended for months, years, any coding or review tips to avoid hanging the processor, say, 1 month into it? 15:52:19 From Amy McNeil : Always look at your compiler output. 15:54:46 From Keith J : Commodore basic and assembly were the only times I've ever used GOTO 16:02:07 From René Andrés Ayoroa : Michael Barr's C coding standard? 16:03:22 From Charles Miller : Using tools like clang-format or uncrustify takes all the argument out of it (except arguments in creating the master format config file!) 16:06:44 From Robert Hancock : I'm a fan of that saying that because debugging is twice as hard as writing the code in the first place, if you write the code as cleverly as you can, then by definition you are not smart enough to debug it.. 16:07:29 From Michael Kirkhart : LOL! 16:07:31 From 주희수 : Reacted to "I'm a fan of that sa..." with 👍 16:07:40 From SR : Reacted to "Using tools like c..." with 👍 16:08:17 From Michael Kirkhart : LOL again! 16:10:15 From Michael Kirkhart : Reacted to "I'm a fan of that ..." with 👍 16:10:43 From Robert Hancock : add 👍 16:10:43 From Amy McNeil : Thank you! 16:10:44 From Robert Hancock : remove 👍 16:11:13 From René Andrés Ayoroa : Thank you Jean 16:11:21 From Vishwa Perera : Thank you Jean 16:11:25 From Erwin Pschernig : Thanks! 16:11:41 From Stephane to Jean Labrosse(Direct Message) : Merci Jean! 16:11:43 From George Addison : Thank you!
This video contains precious pearls: it's a clear explanation of good software practices. Thanks a lot for your work and passion!