Radar Scanner 1.0.0
|
Der hier vorliegende Styleguide ist noch im Entwurfsstudium!
Die in diesem Styleguide enthaltenen Vorgaben sind kein allgemeingültiger Standard sondern eine für einen bestimmten Geschäftsbereich definierte Vorschrift zur Formatierung von Source Code Dateien. Diese Vorschriften können von jeder Organisation eigenständig festgelegt werden und individuelle Unterschiede aufweisen. Der hier vorliegende Styleguide soll dieses Konzept beispielhaft verdeutlichen.
Unabhängig von den hier gezeigten Vorgaben gelten natürlich die als good style akzeptierten Vorgaben, wie sie z.B. von xxx beschrieben wurden.
Zur Beschreibung der Basistypen von Variablen werden die in <inttypes.h> vorgegebenen Definitionen verwendet. Es ergeben sich folgende Vorteile:
Die Definition von Variablennamen erfolgt vorzugsweise in der Kamelhöckerschreibweise.
Variablennamen beginnen mit einem kleinen Buchstaben.
Es sollen die nachfolgend gelisteten Präfixe bei der Definition von Variablennamen verwendet werden. Es ergeben sich folgende Vorteile:
Präfix | Bedeutung | Beispiel |
---|---|---|
p_ | Variable ist ein Zeiger | p_uiEvent |
gp_ | Variable ist ein global verfügbarer Pointer für Schreib- und Lesezugriffe | gp_uiStatus |
gcp_ | Variable ist ein global verfügbarer Konstantenpointer für Lesezugriffe. Der Inhalt der Variable, auf die der Pointer zeigt, kann über den Pointer nicht verändert werden. | gcp_uiTime_ms |
m_ | Variable ist modulglobal, d.h. nur innerhalb des Moduls sichtbar, in dem sie als static deklariert wird. | m_uiWinkelgrad_deg |
kein x_ - Präfix | Varaible ist nur lokal innerhalb des aktuellen Blocks verfügbar | uiZaehler |
Abkürzungen für bestimmte Datentypen:
(diese sind maschinenabhängig und beziehen sich hier auf den MSP430)
Die Typabkürzungen werden ohne Trennzeichen direkt dem Variablennamen vorangestellt. Der Variablennamen beginnt dann mit einem Großbuchstaben.
Präfix | Bedeutung | Beispiel |
---|---|---|
uc | uint8_t | ucData |
c | int8_t | cDifference |
ui | uint16_t | uiFrequenz |
i | int16_t | iDistance |
ul | uint32_t | ulCount |
l | int32_t | lValue |
f | float | fGewicht |
d | double | dToleranz |
Der Zugriff auf Aktoren oder Sensoren erfolgt über einen standardisierten Satz von Funktionen (API):
XY-Init()
XY-Start()
XY-Write()
XY-Read()
XY-Stop()
Sofern bestimmte Funktionen für den Betrieb der Hardware nicht erforderlich sind, können diese weggelassen werden
Zu Beginn jeder Sourcedatei soll ein Header über die Bedeutung der Sourcedatei informieren. Der hier enthaltene Text soll als Vorlage verwendet werden. Die enthaltenen Beispieltexte müssen ersetzt werden. Die Bedeutung der doxygen tags ist der doxygen Dokumentation zu entnehmen:
[doxygen Handbuch] (http://www.stack.nl/~dimitri/doxygen/manual/markdown.html)
Zu Beginn jeder Funktion soll ein Header über die Bedeutung der Funktion informieren. Der hier enthaltene Text soll als Vorlage verwendet werden. Die enthaltenen Beispieltexte müssen ersetzt werden. Die Bedeutung der doxygen tags ist der doxygen Dokumentation zu entnehmen:
[doxygen Handbuch] (http://www.stack.nl/~dimitri/doxygen/manual/markdown.html)
Wichtig:
Nicht verwendete tags sollen entfernt werden, damit die erzeugte Dokumentation möglichst kurz und übersichtlich bleibt. Die tags sind dann bei Bedarf in der vorgesehenen Reihenfolge wieder einzufügen.
Das tag riskman gehören nicht zu den doxygen Standardtags sondern ist eine benutzerabhängige Erweiterungen, die im doxygen Konfigurationsfile unter ALIASES definiert werden muss.
Doxygen kann Grafiken zu den Abhängigkeiten der Source-Dateien erstellen, wenn das Tool graphviz-dot auf dem Rechner installiert ist. Der bin-Pfad der Installation muss im doxygen-File hinterlegt sein.
Die CCS-IDE ist von Eclipse abgeleitet. Es gibt daher die in Eclipse definierte Vorgehensweise, bei der Neuanlage von Dateien vorkonfigurierte Templates zu erstellen. Die Einstellung der Template erfolgt unter dem Menüpunkt /Window/Preferences/Code Style/Code Templates/Files