Update of "Coding Guidelines"
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID: acbbb6cb52815a57e5208be55b76de53b31e55d9
Page Name:Coding Guidelines
Date: 2018-11-07 18:45:10
Original User: maxi
Parent: fc33861db22a0698644f4f83709d7e3dca640223
Content

# Coding guidelines for CLINL

These guidelines shall be applied in every file that is pushed to the CLINL-Repository. Noncompliant modifications will be rejected.

## Basic Principle

The sheer act of coding cleanly is a hard strain which is often neglected in order to better fulfill other duties. In order to counteract several strategies can be applied. One such for example is the act of refactoring one's code after having a working codebase.

## The boy scout's rule

The boy scout's rule states that you shall leave a ground cleaner than what you found it. Analog to that, every programmer who pushes changes to the CLINL-Repository shall refactor, no matter how small the effect, every file he enters. This way, we can guarantee long-lasting high code quality standards.

## The Makefile

The makefile is individual. Every contributor shall keep a local copy of his makefile in order to be able to reuse it even after pulling code from others. Code quality doesn't matter in the makefile

## Code ### Functions Functions shall not be longer than 15 lines. A good function is smaller than 7 Lines. If possible, a function should be inlined. The number of function argument should be reduced, 4 is the upper maximum, anything above should be compacted into a struct exceptions to be made.

### Inline Assembly Inline assembly shall not be used in files other than those inside of the folder ```include/asm_shims```.

### Classes All classes should serve only one single purpose. Splitting too big of a class into two separate classes is often very sensible. Initialisation should always be performed in the most efficient way, which would mean that ``` class a { int b; a (int c) { b = c; } }; ``` becomes ``` class a{ int b; a (int c) : b(c) { } }; ```

### namespaces There are two types of namespaces used in CLINL. Internal namespaces and external namespaces. Internals are used to group the tools used by external namespaces.

### Standard Library If a function is available in the standard library provided in the folder ```include/kstd``` it shall be used instead of making a new implementation of the same concept.

## Unit Testing

The main goal here is to get every single line of code and every single comparison tested by means of unit testing. All the unit tests shall be passed before committing, a push shall only be performed once all unit tests pass.

In order to get a full test coverage the most sensible thing to do is to add to the boy scouts rule. If you enter a file, you shall either refactor or unit test bits of it.

## Efficiency

Speed/Efficiency is king! All of the abovementioned rules shall be broken if and only if a performance boost (no matter how small) can be achieved by doing so.

# Your Responsibilities as a Programmer for CLINL

As a programmer for CLINL, you have to make sure that your code is 1) as fast as possible 2) as clean as possible 3) as secure as possible

# Pre - Commit checklist Before committing make sure that 1) all the unit tests were passed and that none of them failed 2) all your submissions comply with the coding guidelines 3) you don't accidentally push unimportant files like configuration files for your IDE or the build of CLINL (execute ```make clean``` before committing)