Seite(n) 31 - 1 -

Dr.-Ing. habil Jörg Wollnack

Inhaltsverzeichnis

MS Visual C++-Projektstruktur (v10.x) ..................................................................................... 3

Allgemeine Ziele und Regeln des Objekt- und Programmdesigns ........................................... 4

Programm-Notation ...................................................................................................................... 5

Namenskonventionen für C++ Programm-Code ....................................................................... 6

Modifizierte ungarische Notation ................................................................................................ 6 Klassennamen .............................................................................................................................. 6

Zusammensetzung des Variablennamens .................................................................................... 7

Präfixe der Sichtbarkeit ................................................................................................................ 8 Appendizes der Dimension .......................................................................................................... 8 Interface, Schnittstellen und Dimensionen .................................................................................. 9

Dokumentation und Doxygen .................................................................................................... 10 Prozeduren, Klassen und Member ......................................................................................... 10

Source-Code-Verwaltungs-Tools (GIT) .................................................................................... 11

Code-Beispiele ............................................................................................................................. 12

Data Type Ranges ....................................................................................................................... 14

SQL: SQL and C++ Data Types (ODBC) ................................................................................. 15

Escape Sequences ........................................................................................................................ 16

Grafiken zur Benutzung als Ikone ............................................................................................ 17

Anhang ......................................................................................................................................... 18

Variable Naming Conventions ................................................................................................... 18

Object Naming Conventions....................................................................................................... 19

Table Field Naming Conventions ............................................................................................... 21

Window Naming Conventions ................................................................................................... 22

Ungarische Notation ................................................................................................................... 23 Präfixe ................................................................................................................................ 23

Datentypen ......................................................................................................................... 24 Bezeichner .......................................................................................................................... 26

Beispiele ................................................................................................................................. 29

Systems Hungarian .................................................................................................................... 30

Seite(n) 31 - 2 -

Dr.-Ing. habil Jörg Wollnack

Zusammensetzung des Variablennamens .............................................................................. 30 Präfixe der Sichtbarkeit ...................................................................................................... 31

Seite(n) 31 - 3 -

Dr.-Ing. habil Jörg Wollnack

MS Visual C++-Projektstruktur (v10.x)

Abb. 1: Projektstruktur

Bemerkung:

1. Projektinformationen eintragen und in Dokumenten pflegen, damit Programmentwicklung

in Teams möglich wird.!!!!!!.

siehe .\RoboterInterface\Fanuc\RobotActuatorCameraLaserScanner\Diblook.dsw

2. Programmierung erfolgt nach dem Systems Systems Hungarian (Mindeststandard).

Seite(n) 31 - 4 -

Dr.-Ing. habil Jörg Wollnack

Allgemeine Ziele und Regeln des Objekt- und Programmdesigns

1. Strukturieren Sie die Objekte und Programme.

2. Führen Sie das Auge des Programmlesers durch Leeerzeichen und Carriage Return.

3. Die Namensgebung der Objekte soll für sich selbstsprechende Informationen liefern.

4. Weitere Kommentare sollen die Objekte und Programme erklären. Dies gilt sowohl für den

Autor als auch Andere. Denken Sie daran, dass der Autor auch nach relativ langer Zeit sein

Programm schnell und sicher verstehen muss.

5. Beschreiben Sie den Definitionsbereiche und Wertevorrat von Objekten.

6. Nicht definierte Zustände müssen in der Regel abgefangen werden.

7. Dialoge gehören in der Regel nicht in die Module. Der Anwender entscheidet in der

Verwendung der Module was automatisiert und was per Dialog ablaufen soll.

8. Programme möglichst allgemein schreiben. Spezielle Lösungen sind wirtschaftlich wenig

interessant. Deshalb ist Verallgemeinerung und Abstraktion von zentraler Bedeutung für den

Programmentwurf.

9. Module bekommen eigene Testprojekte.

10. Letztlich kann nur die Code-Inspektion durch den Menschen Fehler finden. Jedoch ist das

Konzentrationsvermögen des Menschen beschränkt.

11. Automatisch generierte Testfälle sind wirtschaftlich attraktiv, jedoch haben Sie ihre

systembedingten Grenzen.

12. Absolute Fehlerfreiheit ist und bleibt eine Illusion, weshalb sicherheitsrelevante Hard- und

Software nach gleicher Spezifikation von unterschiedlichen Projektteams entwickeln werden

müssen. Eine Majoritätsentscheidung in der Hard- oder Softwarelösung erhöht statistisch die

Sicherheit. Zudem sollten einfache Hard- und Softwarepfade beim Ausfall des

Hauptsystems eine sichere Notfunktion gewährleisten. Das Watchdog-Konzept wird meist

soft- und hardwaremäßig umgesetzt und bewirkt im Fehlerfall ein definiertes

Wiederaufsetzen des Systems. Letztlich liegen die Probleme in den kritischen Fehler-

szenarien, die der Mensch übersehen oder unbewusst bzw. ungewollt eingebaut hat. Dies

zeigt auch die prinzipiell existierenden Grenzen der Kalkulation von Ausfallwahrscheinlich-

keiten auf.

13. Grundsätzlich gilt die einfache Regel: So komplex wie nötig und so einfach wie möglich.

Dies ist sowohl aus Sicherheits- als auch Wirtschaftlichkeitsgesichtspunkten letztlich das

Beste. Hier tut sich natürlich ein Spannungsfeld zur 8. Regel auf.

Seite(n) 31 - 5 -

Dr.-Ing. habil Jörg Wollnack

Programm-Notation

Beispiele für einen guten Programmierstil:

Übersichtliches Programmieren:Das Auge muss geführt werden.

Strukturieren Sie die Daten, ansonsten sind komplexe Projekte nicht mehr erfolgreich zu bearbeiten

Klammern nach Pascal und nicht nach C einrücken.Nicht zu weites Einrücken, da bei tieferen Schachtelungennicht mehr lesbar.

Abb. 2: Programmstruktur

Übersichtliches Programmieren:Das Auge muss geführt werden.

Strukturieren Sie die Daten, ansonsten sind komplexe Projekte nicht mehr erfolgreich zu bearbeiten.

Namen müssen für sich sprechen und Informationenzum Verständnis liefern. Kommentare erklären weitereDetails.

Abb. 3: Programmstruktur

Seite(n) 31 - 6 -

Dr.-Ing. habil Jörg Wollnack

Namenskonventionen für C++ Programm-Code

Modifizierte ungarische Notation

Klassennamen

Der Klassenname wird mit einem Präfix C versehen und mit einen Compilerschalter MFC_CLASS

auf der Basisklasse CObject erstellt. Header- und Implementationsfile-Namen verzichten in der

Regel auf den Präfix C.

Beispiel: //---------------------------------------------------------------------------------------- CODIERUNG: FILENAME : HDISK = ..\RelativeDirectory ClassName.h Header ClassName.cpp Implementation //---------------------------------------------------------------------------------------- class CClassName #ifdef MFC_CLASS : public CObject #endif //---------------------------------------------------------------------------------------- { }; //----------------------------------------------------------------------------------------

Seite(n) 31 - 7 -

Dr.-Ing. habil Jörg Wollnack

Zusammensetzung des Variablennamens

Bezeichner nur aus dem Präfix, welcher dem Datentyp entspricht, und dem frei gewählten Namen

zusammengesetzt.

Präfix Datentyp Beispiel

Zeichenketten

cp null-terminierter String cpLastName (Text\0 “Text“)

str CString strInfo

Datentypen

b Boolean oder

BOOL unsigned char bBusy

ch char chName

i integer iSize

s short sNumber

w word wNumber

d double dNumber

u unsigned uiNumber

l long liNumber

Referenzen, Pointer und Arrays

r Ref auf double rdNumber

p Pointer pMemory

A Arrays ACounter

Die einzelnen Präfixe lassen sich auch kombinieren.

Seite(n) 31 - 8 -

Dr.-Ing. habil Jörg Wollnack

Präfixe der Sichtbarkeit

Zusätzlich lassen sich Präfixe für Variablensichtbarkeit definieren:

Präfix Sichtbarkeit Beispiel

m_ Member-Variable m_cpLastName

p_ Methodenparameter p_iNewValue

I_ Interfaceparameter (Argument von Funktionen) I_nNewValue

s_ statische Variable s_iInstanceCount

g_ globale Variable g_iTimestamp

Appendizes der Dimension

Zusätzlich lassen sich Appendizes für Variablen-Dimensionen definieren.

Standardmäßig wird das MKS-System der Basiseinheiten ohne Verwendung von Appendizes

eingesetzt.

Appendix Dimensionen Beispiel

Speed in m/s double m_dSpeed;

Acceleration in m/s2 double m_dAcceleration;

Position in m double m_dPosx;

Orientierung in Radiant double m_dThetax;

R Relative Angaben double m_dSpeed_R; (Value/Norm)

PZ Speed in Prozent double m_dSpeed_PZ; (Value/Norm*100)

mm Position in mm double m_dPosx_mm;

grad Orientierung in grad double m_dThetax_grad;

Seite(n) 31 - 9 -

Dr.-Ing. habil Jörg Wollnack

Interface, Schnittstellen und Dimensionen

In den Kernprogrammen, Headern, Moduln usw. werden grundsätzlich MKS Einheiten und RPY

Posen in m und rad herangezogen (siehe auch Abb. 4). Dialoge, Init-Files bzw. Schnittstellen des

Human-Interfaces werden in den für den Anwender gebräuchlichen Dimensionen angeboten, wie

z. B. RPY Posen in mm und grad.

KernprogrammeHeaderModuleDLLsLibs

MKS Einheitenm, s, rad, RPY-Pose usw.

MKS Einheitenm, s, rad, RPY-Pose usw.

Spezifische Einheitenmm, min, grad, Pose usw.

User compatible dimensions

mm, min, grad, RPY-Pose usw.Dialogs

Init-Files

Data-Files

Interface

Applicationabstraction layer

Specificapplication layer

Abb. 4: Interface

Analog sind die Interface zu den Maschinen und technischen Systemen zu entwickeln. Im

Application Abstraction Layer werden standardisierte Interface realisiert, die in den verschiedenen

Applikationen herangezogen werden. Die Anpassung an die spezifischen Gegebenheiten der

Maschinen und technischen Systemen erfolgt im Specific Application Layer.

Beispiel:

Application Abstraction Layer: Geschwindigkeitsangaben in m/s

(Konstruktor oder Member)

Variable: double dSpeed;

Konvertierung im Interface im Specific Application Layer (Konstruktor oder Member)

dSpeed_PZ = dSpeed / dMaxSpeed * 100;

dSpeed = dSpeed_PZ/100 * dMaxSpeed;

Application Abstraction Layer: Geschwindigkeitsangaben in Prozent

Variable: double dSpeed_PZ ;

Interne notwendige Information double dMaxSpeed;

Seite(n) 31 - 10 -

Dr.-Ing. habil Jörg Wollnack

Dokumentation und Doxygen

Informationen zu Doxgen C:\Program Files\doxygen\doxygen_manual.chm

Examples C:\Program Files\doxygen\examples

Info-File <<>>

Prozeduren, Klassen und Member

Seite(n) 31 - 11 -

Dr.-Ing. habil Jörg Wollnack

Source-Code-Verwaltungs-Tools (GIT)

Informationen zu Git <<..\..\GitInfos\InfosGit.docx>>

Seite(n) 31 - 12 -

Dr.-Ing. habil Jörg Wollnack

Code-Beispiele

class CMasterControlXML #ifdef MFC_CLASS : public CObject #endif //---------------------------------------------------------------------------------------------------------------------------------------- { protected: CString m_strErrorInfo; //! Error Information BOOL m_bSaveFileDlg; //! Save file dialog for the teach point file CString m_strPathFileNameExt; //! Path file name extention of the task list file of CMoveList BOOL m_bUseTeachPointsRobot; //! Use teach points Robot CString m_strFileNameTeachPointsRobot; //! File name Teach points robot BOOL m_bUseTeachPointsLaserScanner; //! Use teach points Laser Scanner CString m_strFileNameTeachPointsLaserScanner; //! File name Teach points robot CMove m_CMove; //! Move class object private: BOOL bMoveRobot(CMoveListElement& Move); BOOL bMoveLaserScanner(CMoveListElement& Move); BOOL bMoveLaserScanner(CListW<CMoveListElement,CMoveListElement&>& MoveListLaserScanner); BOOL bMeasurePosition(CMoveListElement& Move);

Seite(n) 31 - 13 -

Dr.-Ing. habil Jörg Wollnack

public: void *m_vpRobotInterface; //! Pointer to robot interface // Laser Scanner System void *m_vpTimerProcData; //! Thread timer interface CLaserScannerSystem *m_pLaserScannerSystem; //! Pointer to laser scanner system CListW<CMoveListElement,CMoveListElement&> *m_pTaskList; //! Pointer auf Tasklist

: : :

: : :

: : : }; //----------------------------------------------------------------------------------------------------------------------------------------

Seite(n) 31 - 14 -

Dr.-Ing. habil Jörg Wollnack

Data Type Ranges

C/C++ recognizes the types shown in the table below.

Type Name Bytes Other Names Range of Values

int * signed,

signed int System dependent

unsigned int * unsigned System dependent

__int8 1 char,

signed char –128 to 127

__int16 2

short,

short int,

signed short int

–32,768 to 32,767

__int32 4 signed,

signed int –2,147,483,648 to 2,147,483,647

__int64 8 none –9,223,372,036,854,775,808 to

9,223,372,036,854,775,807

char 1 signed char –128 to 127

unsigned char 1 none 0 to 255

short 2 short int,

signed short int –32,768 to 32,767

unsigned short 2 unsigned short int 0 to 65,535

long 4 long int,

signed long int –2,147,483,648 to 2,147,483,647

unsigned long 4 unsigned long int 0 to 4,294,967,295

enum * none Same as int

float 4 none 3.4E +/- 38 (7 digits)

double 8 none 1.7E +/- 308 (15 digits)

long double 10 none 1.2E +/- 4932 (19 digits)

The long double data type (80-bit, 10-byte precision) is mapped directly to double (64-bit, 8-

byte precision) in Windows NT and Windows 95.

Signed and unsigned are modifiers that can be used with any integral type. The char type is

signed by default, but you can specify /J to make it unsigned by default.

The int and unsigned int types have the size of the system word. This is two bytes (the same

as short and unsigned short) in MS-DOS and 16-bit versions of Windows, and 4 bytes in 32-bit

operating systems. However, portable code should not depend on the size of int.

Microsoft C/C++ also features support for sized integer types. See __int8, __int16, __int32,

__int64 for more information. Also see Integer Limits.

Seite(n) 31 - 15 -

Dr.-Ing. habil Jörg Wollnack

SQL: SQL and C++ Data Types (ODBC)

Home | Overview | How Do I | FAQ | Sample | Tutorial | ODBC Driver List

Note This information applies to the MFC ODBC classes. If you’re working with the MFC DAO

classes, see the topic Comparison of Microsoft Jet Database Engine SQL and ANSI SQL in DAO

Help.

The following table maps ANSI SQL data types to C++ data types. This augments the C

language information given in Appendix D of the ODBC SDK Programmer’s Reference on the

MSDN Library CD. ClassWizard manages most data-type mapping for you. If you don’t use

ClassWizard, you can use the mapping information to help you write the field exchange code

manually.

ANSI SQL Data Types Mapped to C++ Data Types

ANSI SQL data type C++ data type

CHAR CString

DECIMAL CString 1

SMALLINT int

REAL float

INTEGER long

FLOAT double

DOUBLE double

NUMERIC CString 1

VARCHAR CString

LONGVARCHAR CLongBinary, CString 2

BIT BOOL

TINYINT BYTE

BIGINT CString 1

BINARY CByteArray

VARBINARY CByteArray

LONGVARBINARY CLongBinary, CByteArray 3

DATE CTime, CString

TIME CTime, CString

TIMESTAMP CTime, CString

1. ANSI DECIMAL and NUMERIC map to CString because SQL_C_CHAR is the default ODBC

transfer type.

2. Character data beyond 255 characters is truncated by default when mapped to CString.

You can extend the truncation length by explicitly setting the nMaxLength argument of

RFX_Text.

3. Binary data beyond 255 characters is truncated by default when mapped to CByteArray.

You can extend the truncation length by explicitly setting the nMaxLength argument of

RFX_Binary.

If you are not using the ODBC cursor library, you may encounter a problem when attempting

to update two or more long variable-length fields using the Microsoft SQL Server ODBC driver

and the MFC ODBC database classes. The ODBC types, SQL_LONGVARCHAR and

SQL_LONGVARBINARY, map to "text" and "image" SQL Server types. A CDBException will

be thrown if you update two or more long variable-length fields on the same call to

CRecordset::Update. Therefore, do not update multiple long columns simultaneously with

CRecordset::Update. You can update multiple long columns simultaneously with the ODBC

API SQLPutData. You can also use the ODBC cursor library, but this is not recommended for

drivers, like the SQL Server driver, that support cursors and don’t need the cursor library.

If you are using the ODBC cursor library with the MFC ODBC database classes and the

Microsoft SQL Server ODBC driver, an ASSERT may occur along with a CDBException if a call

to CRecordset::Update follows a call to CRecordset::Requery. Instead, call

CRecordset::Close and CRecordset::Open rather than CRecordset::Requery. Another

solution is not to use the ODBC cursor library, since the SQL Server and the SQL Server ODBC

driver provide native support for cursors natively and the ODBC cursor library isn’t needed.

Seite(n) 31 - 16 -

Dr.-Ing. habil Jörg Wollnack

See Also SQL: Making Direct SQL Calls (ODBC)

Escape Sequences

Character combinations consisting of a backslash (\) followed by a letter or by a combination

of digits are called “escape sequences.” To represent a newline character, single quotation

mark, or certain other characters in a character constant, you must use escape sequences. An

escape sequence is regarded as a single character and is therefore valid as a character

constant.

Escape sequences are typically used to specify actions such as carriage returns and tab

movements on terminals and printers. They are also used to provide literal representations of

nonprinting characters and characters that usually have special meanings, such as the double

quotation mark ("). Table 1.4 lists the ANSI escape sequences and what they represent.

Note that the question mark preceded by a backslash (\?) specifies a literal question mark in

cases where the character sequence would be misinterpreted as a trigraph. See Trigraphs for

more information.

Table 1.4 Escape Sequences

Escape Sequence Represents

\a Bell (alert)

\b Backspace

\f Formfeed

\n New line

\r Carriage return

\t Horizontal tab

\v Vertical tab

\' Single quotation mark

\" Double quotation mark

\\ Backslash

\? Literal question mark

\ooo ASCII character in octal notation

\xhhh ASCII character in hexadecimal notation

Microsoft Specific —>

If a backslash precedes a character that does not appear in Table 1.4, the compiler handles

the undefined character as the character itself. For example, \x is treated as an x.

END Microsoft Specific

Escape sequences allow you to send nongraphic control characters to a display device. For

example, the ESC character (\033) is often used as the first character of a control command

for a terminal or printer. Some escape sequences are device-specific. For instance, the

vertical-tab and formfeed escape sequences (\v and \f) do not affect screen output, but they

do perform appropriate printer operations.

You can also use the backslash (\) as a continuation character. When a newline character

(equivalent to pressing the RETURN key) immediately follows the backslash, the compiler

ignores the backslash and the newline character and treats the next line as part of the

previous line. This is useful primarily for preprocessor definitions longer than a single line. For

example: #define assert(exp) \

( (exp) ? (void) 0:_assert( #exp, __FILE__, __LINE__ ) )

Seite(n) 31 - 17 -

Dr.-Ing. habil Jörg Wollnack

Grafiken zur Benutzung als Ikone

100 DPI 256 Farben-Modus

100 DPI RGB 24 Bit

Seite(n) 31 - 18 -

Dr.-Ing. habil Jörg Wollnack

Anhang

Variable Naming Conventions

See Also

Follow this suggested format for naming variables.

Syntax

[Scope]TypeName

Arguments

Scope

Optional. A convention for noting the range of reference for the variable. For example, local

variables can be prefixed with "l," which reminds you that they can referenced only within the

procedure they were defined in. Suggested expressions for Scope are as follows.

Scope Description Example

l Local lnCounter

p Private (default) pnStatus

g Public (global) gnOldRecno

t Parameter tnRecNo

Type

Convention for noting the data type of a variable. Suggested prefixes for Type are as follows.

Type Description Example

a Array aMonths

c Character cLastName

y Currency yCurrentValue

d Date dBirthDay

t Datetime tLastModified

b Double bValue

f Float fInterest

l Logical lFlag

n Numeric nCounter

Seite(n) 31 - 19 -

Dr.-Ing. habil Jörg Wollnack

o Object oEmployee

u Unknown uReturnValue

Remarks

Prefixes aren't required, but are recommended as good programming practice. Using a prefix does

not dictate the value of a variable — in Visual FoxPro, prefixes are used only as a naming

convention. For example, adding the prefix "c" does not check that only character data is stored to

the variable, but it does help you remember that the variable was created to accept character data.

Note The scope prefix is recommended but not required. In some cases, explicit scoping does not

apply. For example, in the main program of a stand-alone application, there is no difference in

visibility for variables scoped as PUBLIC or PRIVATE. The type prefix is always relevant and is

required in sample programs.

For more information, see Visual FoxPro Naming Rules.

Object Naming Conventions

See Also

Follow this suggested format for naming objects.

Syntax

PrefixName

Suggested prefixes for object names are listed in the following table.

Prefix Object Example

acd ActiveDoc acdHomePage

chk CheckBox chkReadOnly

cbo ComboBox cboEnglish

cmd CommandButton cmdCancel

cmg CommandGroup cmgChoices

cnt Container cntMoverList

ctl Control ctlFileList

<user-defined> Custom user-defined

edt EditBox edtTextArea

frm Form frmFileOpen

frs FormSet frsDataEntry

grd Grid grdPrices

Seite(n) 31 - 20 -

Dr.-Ing. habil Jörg Wollnack

grc Column grcCurrentPrice

grh Header grhTotalInventory

hpl HyperLink hplHomeURL

img Image imgIcon

lbl Label lblHelpMessage

lin Line linVertical

lst ListBox lstPolicyCodes

olb OLEBoundControl olbObject1

ole OLE oleObject1

opt OptionButton optFrench

opg OptionGroup opgType

pag Page pagDataUpdate

pgf PageFrame pgfLeft

prj ProjectHook prjBuildAll

sep Separator sepToolSection1

shp Shape shpCircle

spn Spinner spnValues

txt TextBox txtGetText

tmr Timer tmrAlarm

tbr ToolBar tbrEditReport

Remarks

Prefixes aren't required, but are recommended as good programming practice. Using a prefix does

not dictate the contents of an object variable — in Visual FoxPro, prefixes are used only as a

naming convention. For example, adding the prefix "cbo" does not check that the object referenced

by the variable is a combo box, but it does help you remember the object referenced by the variable.

For more information, see Visual FoxPro Naming Rules.

Seite(n) 31 - 21 -

Dr.-Ing. habil Jörg Wollnack

Table Field Naming Conventions

See Also

Follow this suggested format for naming fields in tables. These conventions are recommended, not

required.

Syntax

Alias.TypeName

Arguments

Type

Notes the data type for a field in a table. Suggested prefixes for Type are as follows.

Type Description Example

c Character Customer.cLastName

d Date Customer.dBirthDay

t Datetime Customer.tLastMod

b Double Customer.bRate

f Float Customer.fValue

g General Customer.gPicture

l Logical Customer.lSellMail

m Memo Customer.mComments

y Currency Customer.yYearTDate

n Numeric Customer.nItems

I Integer Customer.iCustID

Remarks

Prefixes aren't required, but are recommended as good programming practice. Using a prefix does

not dictate the contents of a field — in Visual FoxPro, prefixes are used only as a naming

convention. For example, adding the prefix "d" does not check that the contents of a field is a date,

but it does help you remember the data type contained in the field.

For more information, see Visual FoxPro Naming Rules.

Seite(n) 31 - 22 -

Dr.-Ing. habil Jörg Wollnack

Window Naming Conventions

See Also

Follow this suggested format for naming windows.

Syntax

wName

Remarks

Do not use a prefix on class definitions; use prefixes only when the object is instantiated.

Example

When creating a window object, use the following code:

DEFINE WINDOW wCustomerInvoices ;

FROM nFirstRow, nFirstColumn TO nLastRow, nLastColumn

For more information, see Visual FoxPro Naming Rules.

Seite(n) 31 - 23 -

Dr.-Ing. habil Jörg Wollnack

Ungarische Notation

Quelle: http://de.wikipedia.org/wiki/Ungarische_Notation

Präfixe

Das am strengsten sinn-bezogene Attribut des ungarischen Variablennamens ist das Präfix. Es

nimmt nur Bezug auf die Funktion der Variablen im Programm, in dem sie verwendet wird.

Die nachstehend aufgeführten Präfixe sind die bereits vereinbarten. Man kann allerdings

jederzeit neue (eigene) verwenden, um neue Aufgaben zu spezifizieren (Dokumentation nicht

vergessen!). In der Regel erweisen sich die folgenden Präfixe allerdings als absolut

ausreichend.

Präfix abgeleitet

von Bedeutung

p pointer Ein Zeiger zu einer Adresse.

h handle

Ein Zeiger auf einen Zeiger, also äquivalent zu pp. Fast immer wird h im

Zusammenhang mit der Kommunikation mit dem Betriebssystem

benutzt.

rg range

Ein Array, welches durch „normale“ Integer indiziert wird. Das Array rg

kann als Intervall einer mathematischen Funktion verstanden werden, bei

der jeder ganzen Zahl ein Element zugeordnet wird. Ein rgd etwa ist ein

Array das Gleitkommazahlen doppelter Genauigkeit, enthält.

mp map

Ebenfalls ein Array, mit dem Unterschied zu rg, dass hier zum Indizieren

beliebige Datentypen verwendet werden, zum Präfix mp werden also

zwei Datentypen notiert, nämlich zunächst der Datentyp des Index, und

dann der Datentyp des Inhalts. Ist x ein beliebiger Datentyp, so ist mpix

äquivalent zu rgx.

dn domain

Noch ein Präfix für ein Array: Die Besonderheit von dn ist, dass dieses

Präfix betont, dass das Wichtige nicht die Elemente des Arrays, sondern

die Indizes selbst sind, was dieses Präfix sehr selten macht.

i index

Eines der wichtigsten Präfixe im Zusammenhang mit Arrays. Z. B.

indiziert id ein rgd. Bei einem mpfr, also einem Array von

Gleitkommawerten, indiziert von einem booleschen Datentyp, kann man

den Index als ifr oder schlicht ir deklarieren (obwohl er einen booleschen

Datentyp haben muss).

b base

Ein sehr seltenes Präfix, das jedoch ähnlich wie i ist, nur, dass b den

direkten Offset eines Elementes in einem Array beschreibt. Ist das Array

vom physischen Datentyp Byte, so sind b und i sogar gleich. Ist dch die

physische Länge der Elemente eines Arrays rgx, dann gilt für den Index

ix (beginnend bei 0): bx = dch * ix.

e element Das Pendant zu i. e kennzeichnet ein Element eines Arrays und wird

meistens in Verbindung mit dn genutzt und ist dementsprechend selten.

Seite(n) 31 - 24 -

Dr.-Ing. habil Jörg Wollnack

Dennoch kann auch ein Element des Arrays rgd mit ed bezeichnet

werden, auch wenn dies in den meisten Fällen nicht zweckdienlich ist.

c count Eine Anzahl von Elementen, etwa in einem Array. Die Größe eines rgul

kann als cul angegeben werden.

d difference

Ein Unterschied zwischen zwei Variablen, meistens in einem Array.

Dabei sollte man nicht den Fehler machen, d mit c zu verwechseln: d

bezieht sich immer auf eine Differenz zwischen Indizes.

gr group

Nicht mit rg zu verwechseln: gr bezeichnet einen Verbund von mehreren

Variablen. Dabei handelt es sich jedoch nicht um ein Array, sondern eine

Anordnung von unterschiedlichen Variablen. gr kann bei einem struct,

record oder einer class benutzt werden.

f flag

Ein Bit in einer Variablen. Nicht zu verwechseln mit dem Datentyp f

oder bit, der sich auf die ganze (physische) Variable bezieht. Das Präfix f

bezeichnet ein Bit in einer Variablen des physischen Datentyps byte,

word, etc., das Flaggencharakter hat.

sh shift

amount

Der Index zu einem Bit (f) in einer Variablen (keinem Array). Ist nur f

gesetzt, hat die Variable den Wert 2sh

.

u union

Eine unspezifische Variable, die unterschiedliche (ungarische)

Datentypen beinhalten kann (wenn dies auch sinnvoll ist). Daher ist

dieses Präfix äußerst selten, denn zwei sinnverschiedene Variable sind

selten kompatibel.

a allocation

Eine Zuordnung, kein Array. a wird als Komplement zu p oder auch h

verwendet, da in a die Dereferenzierung gespeichert wird. Damit ist apl

äquivalent zu l, da es die Variable an der Adresse von l ist, also l selbst.

v

Eine globale Variable. Etwa zum Austausch von Daten. Sollte in der

Praxis sparsam bis gar nicht eingesetzt werden, da es dazu verleitet, den

Sinn der Variablen auszulassen. Wenn die Variable keinen strengen

Zweck hat, ist es meist besser, das Präfix einfach wegzulassen, als ein

konstruiertes v zu notieren.

Datentypen

Um eine bessere Austauschbarkeit von Quellcode zu erreichen, hat man (bzw. Simonyi) sich

auf einige Datentypen oder Basetypes, geeinigt. Dabei stellt man einen leichten „C-

Geschmack“ fest, was die Benennung betrifft (zum Beispiel l wie long für einen 32-Bit-

Integerwert).

Datentyp abgeleitet

von Bedeutung

f flag

Boolesche Datentypen (gemeint ist wieder die Bedeutung, nicht

der physische Datentyp) bzw. Variablen mit Wahrheitswert. Der

Bezeichner sollte den wahr-Zustand der Variablen beschreiben,

wenn sie also true ist.

ch char(acter) Ein Ein-Byte-Zeichen. Meistens in einem nicht

Seite(n) 31 - 25 -

Dr.-Ing. habil Jörg Wollnack

vorzeichenbehafteten (unsigned) Byte oder einem Char

gespeichert.

st string Eine „Pascal“-Zeichenkette, also eine Zeichenkette, deren erstes

Zeichen die Länge des Strings enthält

sz string zero

terminated Ein nullterminierter String, wie er in C implementiert ist (char *)

fn function Meistens ein Zeiger auf eine Methode.

fl file Eine Datei bzw. eine Datenstruktur, meistens vom Betriebssystem

übergeben.

w word

Ein Maschinenwort, meistens zwei Byte groß und

vorzeichenbehaftet. Gemeint ist allerdings nicht zwingend die

Implementation im physischen Datentyp word. Wie bei der

AppsUN üblich, ist der Zweck gemeint. Etwa eine generische

Benutzung der Variablen mit entsprechenden Methoden kann ein

w rechtfertigen.

b byte Ein Byte, welches ebenfalls nicht an den gleichnamigen

physischen Datentyp gebunden ist (siehe w).

l long Ein Doppelwort, also vier Byte, ebenfalls nicht an long (C) oder

Integer (Pascal) gebunden (siehe w).

uw unsigned

word Nicht vorzeichenbehaftetes Maschinenwort.

ul unsigned

long Nicht vorzeichenbehaftetes Doppelwort.

r real Gleitkommawert mit einfacher Genauigkeit. In C etwa float.

d double Gleitkommawert mit doppelter Genauigkeit (double).

bit Ein einzelnes Bit. Kann meist besser mit einem ‚f‘ (flag)

bezeichnet werden.

v void Eine leere Variable ohne Datentyp. Wird nur in Verbindung mit

einem Zeiger verwendet (pv).

env environment Wird für Labels, also Sprungziele verwendet (Pascal: goto

envLoop;).

sb segment base Ein Segmentzeiger auf den Speicher (siehe Assemblersprache).

ib

Eine Offsetadresse. Tatsächlich hat dieser Name zwei Gründe.

Zunächst kann die Variable als Index (i) zu einem Array von Bytes

(b) angesehen werden, wenn man sich das RAM als Array

vorstellt. Außerdem kann man ib auch von indivisible base

ableiten.

Seite(n) 31 - 26 -

Dr.-Ing. habil Jörg Wollnack

Bezeichner

Oft reichen Präfix und Datentyp völlig aus, um eine Variable zu benennen und zu erklären.

Die Variable zum Durchlaufen eines Arrays rgch, ist durch

var ich: Integer; // Pascal

int ich; // C

ausreichend beschrieben. Jedes Beiwort erscheint überflüssig, "nicht-ungarisch" oder schlicht

falsch. Zum Beispiel: ichLauf, ichIndex, ichArray, etc.

Seite(n) 31 - 27 -

Dr.-Ing. habil Jörg Wollnack

Trotzdem benötigt man gelegentlich einen Bezeichner, der die Variable konkret an eine

Aufgabe bindet. Dazu kann man ein beliebiges (selbstverständlich sinnvolles) Wort anhängen.

Man muss nur beachten, keine Unterstriche (_) zu benutzen und das Wort nach der Form

„Xxxxx“ zu notieren (also nur den ersten Buchstaben groß zu schreiben). Zu diesem Zweck

gibt es bereits einige vereinbarte Wörter, die man aufgrund ihrer häufigen Verwendung

eingeführt hat. Davon beziehen sich die meisten auf ein Array oder eine ähnliche Struktur.

Bezeichner Bedeutung

Bezogen auf Arrays

Min Beschreibt das allererste Element eines Arrays und wird oft im Zusammenhang

mit einem Zeiger oder einem Index gebraucht; pchMin, ichMin.

Mic

(>=Min)

Ähnelt sehr Min, beschreibt jedoch das physisch kleinste Element, welches in

der Praxis fast immer auch Min ist.

First

(>=Mic)

Beschreibt das erste zu benutzende Element eines Arrays. Ist oft an das Präfix i

gebunden; ichFirst.

Last

(>=First)

Eine Variable xxLast ist das Pendant zu xxFirst. Sie wird benutzt, um das letzte

Element eines Arrays zu indizieren.

Most

(>=Last)

In gewisser Hinsicht das Gegenstück zu Min, da es den höchsten Index eines

Arrays angibt.

Lim

(>Most)

Mit Lim wird die Anzahl der Elemente in einem Array angegeben. Damit ist der

Index mit dem Namen xxLim größer als das letzte Element und damit ungültig.

Mac

(>=Lim)

Das Gegenstück zu Mic und damit Max sehr ähnlich. Wie Lim ein ungültiger

Index.

Max

(>=Mac)

Pendant zu Min; wird genutzt, um die tatsächliche Anzahl an Elementen eines

Arrays anzugeben. Dieser Wert ist als Index auf einen Array ebenfalls ungültig.

Ohne Bezug zu einem Array

Nil

Kennzeichnet einen ungültigen Wert, und wird demzufolge sinnvollerweise

meist als Konstante verwendet (siehe Implementation von Pascal: nil). Meistens

sind dort Werte wie „0“ oder „-1“ enthalten.

Null

Ähnlich wie Nil. Kennzeichnet jedoch meist die Zahl „0“, ebenfalls oft als

ungültiges Element. Um Missverständnissen vorzubeugen, sollte eine

gleichzeitige Benutzung von Nil und Null vermieden werden oder ggf. konkret

kommentiert werden.

Src

Dieser Bezeichner wird benutzt, um zu spezifiziern, dass es sich bei der

Variablen um eine Quelle (engl. source) handelt. Etwa bei einem

Transportalgorithmus.

Dest Dest wird oft in Verbindung mit Src benutzt und verweist auf das Ziel (engl.

destination) einer Operation (deren Quelle Src ist).

Sav

Wird als temporärer Speicherplatz für den Wert einer Variablen benutzt. Zu

häufiges Benutzen dieses Bezeichners ist jedoch stilistisch ebenso fragwürdig

wie das Präfix v, da die Variable keine strenge Namensbindung mehr besitzt.

Abgeleitet vom engl. Save.

Seite(n) 31 - 28 -

Dr.-Ing. habil Jörg Wollnack

T

Ähnlich wie Sav, nur dass dieser Bezeichner die Betonung auf noch kürzere

Auslagerungen von Daten legt und somit noch weniger namensgebunden ist. T

sollte man erst recht vermeiden, vor allem jedoch die Produktion vieler

"temporärer" Variablen durch wiederholtes Anhängen von T. Namen wie

xxTTT, xxTTTT oder gar xxT5 sind Anzeichen für falsches Ungarisch und

sollten grundsätzlich nicht benutzt werden.

Darüber hinaus lassen sich natürlich beliebig andere Bezeichner wählen. Jedoch sollte man

sich bemühen, zunächst die Bezeichner der Tabelle zu verwenden. Dies gilt vor allem in

Bezug auf Arrays. Zum Beispiel gibt die Funktion

Length(rgx);

in Pascal die Länge des Arrays rgx zurück. So ist es verlockend, das Ergebnis in einer

Variable culLength zu speichern. Falsch ist diese Lösung nicht, da die Benutzung der

Bezeichner nicht streng ist. Jedoch ist es wünschenswert culMax zu verwenden, um

standardkonform zu programmieren.

Seite(n) 31 - 29 -

Dr.-Ing. habil Jörg Wollnack

Beispiele

Beispiel Bedeutung

rgch Ein Array von Zeichen, anders ausgedrückt eine Zeichenkette. Diese Notation ist

äquivalent zu sz (oder je nach Implementation zu st).

ast Der Wert an der Stelle auf die st zeigt, also das erste Element einer Pascal’schen

Zeichenkette und damit die Anzahl der Elemente. Gleichbedeutend mit cst.

uuluwch

Eine Variable, die sowohl 32-bit, 16-bit wie auch 8-bit große Zahlen speichert. In

der Praxis würde man sich vermutlich mit einem ul begnügen. Es sei denn, es soll

explizit darauf aufmerksam gemacht werden, dass die Zahlen einer bestimmten

Menge von Datentypen angehören.

rgbit

Eine Ansammlung von Marken. Man könnte diese Variable als einen long

implementieren. Hier ist der große Vorzug der Ungarischen Notation. Aus einem

long flags; könnte man schwer eine Bedeutung der Variable flags herauslesen. Aber

ein long rgbit; verweist deutlich auf den Charakter einer Sammlung von Marken.

rggr Ein Array, dessen Elemente Verbunde oder Klassen sind.

mpchgr

Ebenfalls ein Array, dessen Elemente Verbunde oder Klassen sind. Allerdings mit

dem Unterschied zu rggr, dass das Array von ich indiziert wird, also von positiven

Bytes.

Seite(n) 31 - 30 -

Dr.-Ing. habil Jörg Wollnack

Systems Hungarian

Diese Notation ist die Abwandlung der microsoft’schen Windowsprogrammierer und

entspricht nicht mehr dem Sinn, den Simonyi bei der Entwicklung der ungarischen Notation

verfolgt hat.

Zusammensetzung des Variablennamens

Anders als beim Apps Hungarian wird der Bezeichner nur aus dem Präfix, welcher dem

Datentyp entspricht, und dem frei gewählten Namen zusammengesetzt.

Präfix Datentyp Beispiel

n Integer nSize

b Boolean bBusy

sz null-terminierter String szLastName

p Zeiger pMemory

a Array aCounter

ch char chName

dw Double Word, 32 Bit dwNumber

w Word, 16 Bit wNumber

Die einzelnen Präfixe lassen sich auch kombinieren. So definiert paszTabelle einen Zeiger

auf ein Array null-terminierter Strings.

Seite(n) 31 - 31 -

Dr.-Ing. habil Jörg Wollnack

Präfixe der Sichtbarkeit

Zusätzlich lassen sich Präfixe für Variablensichtbarkeit definieren:

Präfix Sichtbarkeit Beispiel

m_ Member-Variable m_szLastName

p_ Methodenparameter p_iNewValue

i_ Interfaceparameter (Argument von Funktionen) i_nNewValue

s_ statische Variable s_iInstanceCount

g_ globale Variable g_iTimestamp