Sure!
Here’s the script from the Naming Conventions part onward:
Slide: Naming Conventions
Presenter’s Script:
"Now, let’s dive into some specific MISRA C rules, starting with naming conventions. MISRA C
emphasizes that local variable and function parameter names should follow a consistent naming
convention. This ensures clarity and maintainability throughout the codebase.
Let’s look at a noncompliant example first."
Noncompliant Code Example:
void doSomething(int my_param) {
int LOCAL;
...
"Here, we have a local parameter my_param, which is acceptable. However, the variable LOCAL is in
uppercase, which violates naming conventions. The uppercase variable name can cause confusion,
especially when maintaining the code in large teams or over time. Let’s see how this should be
written according to MISRA C."
Compliant Code Example:
void doSomething(int myParam) {
int local;
...
"Notice how both the parameter and the local variable use camelCase for naming. This improves
readability and ensures consistency with typical coding practices. By adopting clear naming
conventions, we avoid potential errors or misunderstandings that can arise from unclear variable
names."
Slide: Control Structures Should Use Curly Braces
Presenter’s Script:
"Next up is the use of curly braces in control structures, which is another important rule in MISRA C.
When writing conditional statements like if, else, or for, it's crucial to always enclose them in curly
braces. This eliminates ambiguity and potential errors in case the statement is later modified.
Here’s an example of noncompliant code."
Noncompliant Code Example:
if (condition) // Noncompliant
executeSomething();
"In this case, the if statement lacks curly braces, which might seem harmless now. However, as the
code grows or changes, it's easy to forget to add braces or misinterpret the code structure. Now let’s
look at the compliant version."
Compliant Code Example:
if (condition) {
executeSomething();
"As you can see, the use of curly braces here makes the intention of the code clear and safe,
particularly when additional statements need to be added within the block later."
Slide: Switch Cases Should End with a Break Statement
Presenter’s Script:
"Now, let’s talk about switch-case statements. A very important MISRA C rule is that every switch
case should end with an unconditional break statement. This ensures that control doesn’t
inadvertently 'fall through' from one case to another.
Here’s an example of a noncompliant switch case."
Noncompliant Code Example:
switch (myVariable) {
case 1:
foo();
break;
case 2: // Both 'doSomething()' and 'doSomethingElse()' will be executed. Is it on purpose?
doSomething();
default:
doSomethingElse();
break;
"In this case, if myVariable equals 2, both doSomething() and doSomethingElse() will execute, which
is likely not the intended behavior. This happens because the case lacks a break statement, causing
the execution to 'fall through' to the next case.
Here’s how we can fix that."
Compliant Code Example:
switch (myVariable) {
case 1:
foo();
break;
case 2:
doSomething();
break;
default:
doSomethingElse();
break;
"By ensuring that each case ends with a break statement, we make the flow of control explicit and
prevent unintentional behavior from occurring."
Slide: Avoiding Multiple Return Points for Errors
Presenter’s Script:
"Let’s take a look at another common rule that helps improve maintainability—avoiding multiple
return points for error handling.
Here’s a problematic code example."
Problematic Code Example:
static bool_t f (uint16_t n, const char *p) {
if (n > MAX) {
return false; // Non-compliant
if (p == NULL) {
return false; // Non-compliant
return true;
"In this code, we have two separate return statements for error handling, making it harder to follow
the logic. It’s a best practice to consolidate error handling in one place. Let’s see how we can fix it."
Compliant Code Example:
static bool_t f (uint16_t n, const char *p) {
if (n > MAX || p == NULL) {
return false;
return true;
"By combining the error checks into a single conditional statement, we improve readability and make
future code changes easier to manage."
Slide: Implementing MISRA in Embedded Systems
Presenter’s Script:
"Now that we’ve covered a few of the key rules, let’s talk about how to implement MISRA C
guidelines in your embedded systems development process.
To successfully integrate MISRA C, there are several steps you should follow:
1. Selecting the appropriate MISRA standard – Choose the version that best suits your project
needs.
2. Understanding the guidelines – Ensure all team members are trained and familiar with the
rules.
3. Setting up development tools – Use static code analyzers and compilers that support MISRA
checks.
4. Establishing coding standards – Align your internal coding standards with the MISRA
guidelines.
5. Code reviews and inspections – Conduct thorough reviews to catch deviations early.
6. Static code analysis – Automate rule enforcement wherever possible.
7. Testing and verification – Verify both functionality and MISRA compliance.
8. Documentation and traceability – Keep detailed records of compliance efforts.
9. Training and education – Continuously train your team on new guidelines and best practices.
10. Continuous improvement – Regularly review and update your coding practices.
By following these steps, you can ensure that your software is safer, more reliable, and easier to
maintain."
Feel free to adjust the tone or wording based on your presentation style! Let me know if you need
further modifications.