Download - FESG - Technische Universität München

14 KAPITEL 1: EINFÜHRUNG
1. Notationserweiterung: Präfix steht direkt vor Bezeichner
An dieser Stelle werden Typinformationen durch vorangestellte eindeutige
Buchstaben codiert (z.B. „c“ für Character, „i“ für Integer, „S“ für Structure,
„C“ für Class usw.)
2. Notationserweiterung: Präfix steht vor 1. Notationserweiterung
An dieser Stelle werden Referenzierungseigenschaften gekennzeichnet (z.B.
„a“ für Array, „az“ für zero-terminated Array, „p“ für C-Pointer, so dass
zusammen mit Präfix 1 z.B. „azc...“ für ein herkömmliche Character- Zeichenkette
mit Nullabschluss steht)
3. Notationserweiterung: Präfix steht vor 2. Notationserweiterung
An dieser Stelle werden Speicherinformationen angezeigt (z.B. „m_“ für
Member-Variablen, „g_“ für globale Variablen, so dass zusammen mit Präfix
1 und 2 z.B. „m_pi...“ für einen Member-Zeiger in C-Notation auf einen
Integerwert steht)
Die Hungarian Notation erzwingt Zudem wird durch die Hungarian Notation die Vergabe von präzisen Namen
präzises Arbeiten vorgeschlagen (Indexvariablen heißen somit nicht mehr nur „i“ sondern z.B. „iIndex“).
Ein gewisser Nachteil ist jedoch, dass Typänderungen eine Vielzahl von
Folgeveränderungen mit sich bringen, was ja eigentlich Sinn und Zweck für die
qualitativ hochwertige Programmierung ist, keine schnellen und evtl. fehlerträchtigen
Veränderungen zuzulassen.
Allgemeingültige Designregeln
für die Fundamentalstation als
ein Ergebnis
Kontrolle von konkurrierenden
Parallelversionen einer Entwicklung
mittels CVS
Dabei kann bereits der erste Erfolg dieser Arbeit genannt werden. Die im Rahmen
der Arbeit erstellten Design- und Umsetzungsvorgaben wurden als Grundlage
der „Design-Rules für die objektorientierte Programmierung in C++ und die strukturierte
Programmierung in C“ 14 verallgemeinert und erweitert und werden in dieser
Form zukünftig auf alle Softwareprojekte mit C und C++ in der Fundamentalstation
Wettzell Anwendung finden.
Versionskontrolle
Versionskontrolle entstand als Koordinierungsschnittstelle bei paralleler Softwareentwicklung
sowohl bei industriellen Großprojekten als auch für Projekte der freien
Softwareentwicklung („Open Source“). Gerade dort, wo zahlreiche Beteiligte
auf der ganzen Welt an denselben Quellen arbeiten und Änderungen einbringen,
ergeben sich unumstrittene Vorteile aus einer Versionskontrolle. Die Organisation
zum Einbringen dieser Rückmeldungen ist manuell unüberwindbar. Zudem
ergibt sich der Bedarf, eingebrachte Veränderungen wieder rückgängig zu
machen, weil sie evtl. fehlerbehaftet sind. In diesem Rahmen entstand der elementare
Einsatz von Dateivergleichsprogrammen (z.B. „diff“) und des Revision
Control System (RCS) . RCS hatte jedoch einige Nachteile. Es stellte keine
Verzeichnisstrukturen bereit, erlaubte nur strikte Sperren kompletter Dateien und
war nicht netzwerkfähig. Die Lösung ergab sich durch das Concurrent Versions
System (CVS) . Es setzte auf RCS auf und löste dessen Probleme. Dadurch
können Dateibäume als komplette Projektbereiche betrachtet und verwaltet
werden. Es ist möglich gleichzeitig an einer Datei zu arbeiten, deren Historie aufgezeichnet
und Veränderungen meist automatisch zusammengemischt („merging“)
14 vgl. dazu die erstellten Designregeln für die Fundamentalstation Wettzell [DASS04]