Before I write about the rules of performance I will do a very simple 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. 

At first, I have to apologize. Today, I wanted to continue my journey through the C++ Core Guidelines with the arithmetic expressions. In my seminar in this week, we had a long discussion about switch statements in C/C++ and how they become totally 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 behaviour. 

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

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

I know the headline to this post is a little 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, you should know the precedence rules for arithmetic or logical expressions, and you should know the order of evaluation of expressions. Having the wrong precedence rules for expressions in mind or assuming an evaluation order for expressions which is just wrong or not guaranteed are the main reasons for undefined behaviour. 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.