@MaxP, that's a great tip about const, to go along with the advice about static!
Another one I heard (related to Rule 16.4 about having a default statement inside every switch statement) is to always include an else statement with any if statement. My thoughts on that are mixed, but I feel like if you buy the MISRA rule, then that also must follow by the same logic.

Re: question about unions in Q&A. We use this pattern below a lot with struct inside union, where we can set all bits easily via "value = 0u":

typedef union
{
uint32_t value;
struct
{
uint32_t bitX : 1;
uint32_t bitY : 1;
// etc
}
} myTypeName_t;

Another example with union inside struct where we can access the data either as bits in a structure, or as a byte array when transmitting/receiving it without needing any conversion functions:-

typedef struct
{
union
{
type_t value;
char bytes[sizeof(type_t)];
}
uint32_t crc;
}
} myTypeName_t;

Sorry about the formatting, can't get Markdown to work!

Thanks again for the feedback Colin! One way I have seen unions being used would be as an event parameter for communication among tasks/threads.
Depending on the event type, different members of the event parameters are accessed (sorry about the formatting):
struct eventDetails
{
event_enum eventType;
union eventParams
{
uint32_t paramForEventA;
uint8_t paramForEventB;
//other params
};
};
Would love to know your thoughts on this.

Hello Collin, what is a good way to learn MISRA standard so that we can implement this guideline in our daily coding style? Is that suggestible for you that we just look through the whole directives and rules of the MISRA? Or do you have any other suggestions from your experience? My personal learning practice of the MISRA or other guidelines like CERT C is read one or two rules every day.

Following and the Q&A question about unions: how would you manage a message structure that can contain different types of data (some simple types, other being structures) ?
I tend to use a struct with a type enum and a data union. I am interesting to see how this topic can be tackled without union.

rule 1.2 : Is there few common examples that illustrate this rule?

Thanks Colin, that was (again) a great talk!
I have one addition regarding rule 5.3: that is not only about global and local variables (which could be distinguished by naming schemes), but also local variables within different scopes:

void bar() {
    int foo = 0;
    if (foo) {
        int foo = 1;
    }
}

I even think I saw cppcheck complaining about such shadowing, but I was not able to reproduce that now.

Thanks Colin! Regarding Rule 17.8 ("don't modify function parameters") - it is common practice to use pointer types as "output" parameters. Do you/MISRA consider this practice maintainable? On a related note, how does MISRA C feel about side-effects in general?

Thanks Colin for a good talk.

Thank you Colin for this concise and informative presentation. I really liked the examples you used to clarify the rules by MISRA. Thank you for sharing!

Thanks Colin, very informative overview of the MISRA C. I'd like to add that to better enforce 17.8 it is possible to declare parameters as "const":

int times2( int n );  // prototype stays the same

int times( int const n )  // n is const int
{
  n *= 2;   // <- error since n is const
  return n;
}