Home > On-Demand Archives > Q&A Sessions >

Live Q&A - Embedded Software Programming Rules, Tips and Tricks

Jean Labrosse - Watch Now - Duration: 39:10

Live Q&A - Embedded Software Programming Rules, Tips and Tricks
Jean Labrosse
Live Q&A with Jean Labrosse for the talk titled Embedded Software Programming Rules, Tips and Tricks
M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

AlessandroDePin
Score: 0 | 4 weeks ago | 1 reply

This video contains precious pearls: it's a clear explanation of good software practices. Thanks a lot for your work and passion!

JeanLabrosseSpeaker
Score: 0 | 4 weeks ago | no reply

Thank you for your kind words.

Rick_D
Score: 0 | 1 month ago | 1 reply

Thanks for your insights. I particularly liked the Global/extern tips/trick

JeanLabrosseSpeaker
Score: 0 | 1 month ago | no reply

You are welcomed.

Kornak.ca-DevServices
Score: 0 | 1 month ago | 1 reply

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?

JeanLabrosseSpeaker
Score: 0 | 1 month ago | no reply

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.

Scott.Becker
Score: 0 | 1 month ago | 1 reply

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.

JeanLabrosseSpeaker
Score: 0 | 1 month ago | no reply

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.

Thomas.Schaertel
Score: 0 | 1 month ago | 1 reply

Hi Jean, like always a great talk. Those great and practical insights help a lot for clean code. Thanks a lot!

JeanLabrosseSpeaker
Score: 0 | 1 month ago | no reply

Thank you Thomas.

AliceWang
Score: 0 | 1 month ago | 1 reply

Clear and straightforward talk! Thank you!

JeanLabrosseSpeaker
Score: 0 | 1 month ago | no reply

Thank you, I'm glad you liked it.

SimonSmith
Score: 1 | 1 month ago | 1 reply

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.

JeanLabrosseSpeaker
Score: 1 | 1 month ago | 1 reply

Thanks for the kind words. All formatted by hand. There was nothing at the time that I was satisfied with to do it automatically.

SimonSmith
Score: 0 | 1 month ago | no reply

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!

OUR SPONSORS