Before I write about the rules of performance, I will do a straightforward job. Accessing the elements of a container one by one.

Today, I will write about the remaining rules to statements and the arithmetic rules. If you don't follow the arithmetic rules, undefined behaviour may kick in.

My last German post C++ Core Guidelines: To Switch or not to Switch, that is the Question got a lot of attention. To use a hash table instead of a switch statement seems to be a highly emotional topic. So I change my original plan. Today, I will present different kinds of control structures. I will start with the if and switch statements, continue with the hash table, and end with dynamic and static polymorphism. Additionally, I will mark a few remarks about performance and maintainability. 

First, I have to apologize. Today, I wanted to continue my journey through the C++ Core Guidelines with arithmetic expressions. In my seminar this week, we had a long discussion about switch statements in C/C++ and how they become unmaintainable. Honestly, I'm not a fan of the switch statements, and I have to say: there is life after the switch statements.

Before I continue with the roughly 15 rules for statements, let me finish the two rules for expressions. Both rules help you to protect your program from undefined behavior. 

This post is about don'ts. Here are this post's two most important rules: Don't use std::move thoughtless and don't slice. Let's start.

What has narrowing conversion and casts in common? They are often the source of errors; therefore, I will write about them today.

I know this post's headline is a bit boring: More Rules for Expressions. Honestly, this post is about code hygiene because I will mainly write about pointers.

Today's post is about expressions. You should avoid complicated expressions, know the precedence rules for arithmetic or logical expressions, and know the order of evaluation of expressions. The main reasons for undefined behavior are having the wrong precedence rules for expressions in mind or assuming an evaluation order for expressions that is just wrong or not guaranteed. I know that's a lot to digest. Let's start.

In this post, I will finish the rules for declarations. The remaining rules for declarations are not especially sophisticated but important for high code quality.