Development guide

This document describes the development guideliness used for developing SDF3. The purpose of this document is to define a uniform style to program, develop, and document SDF3. The rules and recommendations presented here are not final, but should serve as a basis for continued work with C/C++. This collection of rules should be seen as a dynamic document; suggestions for improvements are encouraged.

A large part of this document is based on the Coding Style Guide as written by Applied Informatics. This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

All trademarks or registered marks in this document belong to their respective owners.

Information in this document is subject to change without notice and does not represent a commitment on the part of TU Eindhoven. This document is provided "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the particular purpose.


Introduction

This document describes the development guideliness used for developing SDF3. The purpose of this document is to define a uniform style to program, develop, and document SDF3. The rules and recommendations presented here are not final, but should serve as a basis for continued work with C/C++. This collection of rules should be seen as a dynamic document; suggestions for improvements are encouraged.

Programs that are developed according to these rules and recommendations should be:

  • correct,
  • easy to maintain.
In order to reach these goals, the programs should:
  • have a consistent style,
  • be easy to read and understand,
  • be portable to other architectures,
  • be free of common types of errors,
  • be maintainable by different programmers.
Questions of design, such as how to design a class or a class hierarchy, are beyond the scope of this document. In order to obtain insight into how to effectively deal with the most difficult aspects of C/C++, the provided example code should be carefully studied. C/C++ are a difficult languages and there may be a very fine line between a feature and a bug. This places a large responsibility upon the programmer, as this is always the case when using a powerful tool. Both C and C++ allows a programmer to write compact and, in some sense, unreadable code.

In order to make the code more compact, the examples provided do not always follow the rules. In such cases, the broken rule is clearly indicated.

Optimize code only if you know for sure that you have a performance problem. Modern compilers are pretty good at optimizing code. So, source code that "looks fast" does not necessarily produce faster object code. It only is harder to understand and maintain.
All code that is checked into the repository must be tested using the Microsoft Visual C++ compiler and the GNU C/C++ compiler.
If this style guide leaves anything unclear, see how it has been done in the existing code base and do it accordingly.