Programming Guidelines

#Introduction

This page lays out some guidelines to follow when programming library code within the ReaK platform. These are not guidelines on using the different elements of the library, but since this is an open-architecture library, to use the library often implies extending the library for custom purposes, and these guidelines can be followed to do so harmoniously. Some guidelines will be stressed more than others, depending on their importance.

First, some notes on notation and programming style will be mentioned as a way to show the look and feel of the code, hoping these notation guidelines can be followed to preserve a uniform look. Second, the namespace structure will be briefly laid out. Third, the fundamental building blocks of the library will be described along with guidelines on best practices when using them to program the different types of software elements that compose the ReaK library.

##Notation and Programming Style

All experienced programmers know that notation is not a critical design decision, and, in that sense, is not so important. However, it is desirable, in general, that the notation be kept uniform to increase clarity and self-documenting nature of the code. The section will petition the library programmer to strictly up-hold the chosen notation and programming style. The level of strictness of these guidelines go as follows:

1. The notation must be abide to for all interface code, which includes class and function names, or anything else which is expected to be used by user-side code.
2. The notation should be used for all internal code, which includes private data members, helper functions, private member functions and helper classes. In other words, anything that is expected to be of interest to other developers, code reviewers or users interested in the implementation details.
3. The notation is suggested for implementation code, which includes the body of the functions and elements put in a "detail" namespace, i.e., any code that is only really meant to concern the original developer and possibly an expert reviewer.