EN 
DE Programming with a twist
Author: Andreas Fertig, Philips Medical Systems Böblingen
Presentation at the Embedded Software Engineering Congress 2016
Programming is easy these days. There are dozens of programming languages and many ways to learn them. An important part of the word "programming language" is the language itself. We usually focus on the "programming" part. In embedded systems, programs have a lifespan of many years. Therefore, error-free programming is crucial. Often overlooked is another important goal of programming: communication with other developers. Using a language, we can communicate our intentions for years to come. Language facilitates debugging and makes it easier to extend existing programs. With the evolution of the C++ standard to C++11 and C++14, new possibilities arise for further refining our expression.
Programming and programming languages are primarily used to solve problems. The goal of programming is to create something new or to improve or repair something existing. According to Springer Gabler, a programming language is defined as follows:
A programming language is an artificial language used for communication between humans and computers. It is defined by its syntax and semantics. In a programming language, problem-solving procedures are represented in a form that is "understandable" to the computer. [1]“
In this definition, communication with the computer is paramount; the focus is again on solving a task. If we remove the first part of the word, we are left with "language." According to Pons, language is defined as...
„System of symbols (that serves communication or similar purposes) [2]“
A programming language is therefore not solely for solving problems and communicating with the compiler. Through the programming language, we also communicate with other people who work with our code. They either adopt our code or make changes to it. Code, therefore, is, alongside the specification, another form of documentation, although only the code reflects the actual implementation. For this reason, the code should also be written with the reader in mind.
Google recognized this and took it into account in its coding rules. In his presentation at cppcon 2014, Titus Winter explained the philosophy behind Google's coding rules as follows:„Code is going to live a long time, and be read many times. We choose explicitly to optimize for the reader, not the writer.“
As in Fig. 1 (PDF) As shown, the code fulfills the aspect of communicating with the computer, while at the same time being used for communication between people as well as for documentation purposes.
The first aspect is fairly clear. However, the other two are often overlooked. Every language has the characteristic that sentences can be formulated in different ways. Examples of this are comma placement and spelling. People can still understand the meaning of a sentence even if it is slightly misspelled or a comma is missing. Our best friend, the compiler, tries to emulate humans. It attempts to translate any code into an executable form, as long as it is semantically correct. This code is then executable in the vast majority of cases. The following example is translatable and executable:
void PrintString(char* str) {
for( float x=0.0; nullptr != str[x]; x+=1.0 ) {
printf( „%c “, str[x] );
}
}
Probably no programmer would use a float here. Regardless, it compiles and runs!
What is unclear is the author's intention. Was there a reason to use the float data type, or was it simply a lack of knowledge? If the use of float was intentional, the reason should be commented on directly at the point of use.
Less obvious are examples with references, pointers, or const. C developers, in particular, tend to use pointers out of habit. Pointers function semantically almost identically to references. However, references have two crucial advantages: they can never be NULL, and they must always be initialized directly.
If we interpret a pointer as optional and references as required, we gain a significant increase in expressiveness. A function that takes a reference as a parameter therefore requires a value. If the same function takes a pointer, the value is optional and can be omitted by passing NULL. Now it is up to the called function to handle the NULL pointer.
Using a reference as a parameter also saves the author the often tedious NULL pointer check in the function body. A positive side effect is that the resulting code is smaller and the check cannot be forgotten. Furthermore, a reference signals externally that the function can only be called with valid values.
Another example is `const`. With a parameter, the caller can rely on the data passed to it remaining unchanged. An entire function can be marked as a constant. A call to it then does not modify the class. Extending the `const` hierarchy further, we obtain a complete constant object. In embedded systems, this is highly advantageous because the object never needs to be copied or initialized. It can be stored directly in ROM (read-only memory). In this case, communication with the compiler is used efficiently. Of course, the same code will also run without `const`, but it will require more resources.
With new language features like `override`, we can express that an inherited function should be overridden. Unfortunately, this keyword was added to C++ relatively late, which explains its somewhat unusual semantics. Using `override` is optional; we can currently override virtual functions directly. The benefit lies in this new expressiveness. Programmers can now specify that this particular function should be overridden. They expect the function to exist in the inheritance hierarchy. Now, colleagues can see that the function originates from a base class, and indeed, must. As a further advantage, the compiler provides support and indicates if no such function exists in the hierarchy. Without `override`, it would create the function as a new, independent function. Only during debugging would it be difficult to discover why the function behaves completely differently than expected. It might even never be called.
Meaningful and clear code is a valuable asset. Aside from the compiler and maintenance, there are colleagues who work with the code. They use functions or classes that others have provided. As Robert Murray wrote in 1993 in C++ Strategies and Tactics:„If you use object-oriented technology, you can take any class someone else wrote, and by using it as a base class, refine it to do a similar task. [3]“
Always keep this in mind. The nature of C++ makes it easy to reuse functions or classes. Using `override` and `final`, we can very precisely decide when inheritance should end. We can make this decision at both the function and class levels.
A programming language serves more than just to solve a problem. It is also documentation and communication. Besides the compiler, it is also read by people. Therefore, the eye reads too. Use the language's features to make your code clearer. Protect it against unintended use.
Bibliography and list of sources
[1] Springer Gabler, programming language
[2] Duden, Language
[3] Murray, Robert B., C++ Strategies and Tactics, 1993
Implementation – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of implementation/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Implementation – Expertise
Valuable expertise in the field of implementation/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
