Wichtige Definitionen und Programmdesignregeln

Seite(n) 31
-1-
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
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
-2-
Zusammensetzung des Variablennamens .............................................................................. 30
Präfixe der Sichtbarkeit ...................................................................................................... 31
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
-3-
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).
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
-4-
Allgemeine Ziele und Regeln des Objekt- und
Programmdesigns
1.
2.
3.
4.
Strukturieren Sie die Objekte und Programme.
Führen Sie das Auge des Programmlesers durch Leeerzeichen und Carriage Return.
Die Namensgebung der Objekte soll für sich selbstsprechende Informationen liefern.
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 Fehlerszenarien, die der Mensch übersehen oder unbewusst bzw. ungewollt eingebaut hat. Dies
zeigt auch die prinzipiell existierenden Grenzen der Kalkulation von Ausfallwahrscheinlichkeiten 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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
-5-
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 Schachtelungen
nicht 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 Informationen
zum Verständnis liefern. Kommentare erklären weitere
Details.
Abb. 3: Programmstruktur
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
-6-
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
//---------------------------------------------------------------------------------------{
};
//----------------------------------------------------------------------------------------
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
-7-
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
str
CString
strInfo
(Text\0  “Text“)
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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
-8-
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;
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
-9-
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.
User compatible dimensions
Dialogs
mm, min, grad, RPY-Pose usw.
Init-Files
Kernprogramme
Header
Data-Files
Module
DLLs
Libs
MKS Einheiten
m, s, rad, RPY-Pose usw.
Application
abstraction layer
MKS Einheiten
m, s, rad, RPY-Pose usw.
Interface
Spezifische Einheiten
mm, min, grad, Pose usw.
Specific
application 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:
Variable:
Geschwindigkeitsangaben in m/s
(Konstruktor oder Member)
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:
Variable:
Interne notwendige Information
Geschwindigkeitsangaben in Prozent
double dSpeed_PZ ;
double dMaxSpeed;
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 10 -
Dokumentation und Doxygen
Informationen zu Doxgen
Examples
Info-File
C:\Program Files\doxygen\doxygen_manual.chm
C:\Program Files\doxygen\examples
<<>>
Prozeduren, Klassen und Member
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 11 -
Source-Code-Verwaltungs-Tools (GIT)
Informationen zu Git
<<..\..\GitInfos\InfosGit.docx>>
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 12 -
Code-Beispiele
class CMasterControlXML
#ifdef MFC_CLASS
: public CObject
#endif
//---------------------------------------------------------------------------------------------------------------------------------------{
protected:
CString
m_strErrorInfo;
//! Error Information
BOOL
CString
BOOL
CString
m_bSaveFileDlg;
m_strPathFileNameExt;
m_bUseTeachPointsRobot;
m_strFileNameTeachPointsRobot;
//!
//!
//!
//!
BOOL
CString
m_bUseTeachPointsLaserScanner;
m_strFileNameTeachPointsLaserScanner;
//! Use teach points Laser Scanner
//! File name Teach points robot
CMove
m_CMove;
//! Move class object
Save file
Path file
Use teach
File name
dialog for the teach point file
name extention of the task list file of CMoveList
points Robot
Teach points robot
private:
BOOL
BOOL
BOOL
BOOL
bMoveRobot(CMoveListElement& Move);
bMoveLaserScanner(CMoveListElement& Move);
bMoveLaserScanner(CListW<CMoveListElement,CMoveListElement&>& MoveListLaserScanner);
bMeasurePosition(CMoveListElement& Move);
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 13 -
public:
void
*m_vpRobotInterface;
//! Pointer to robot interface
*m_vpTimerProcData;
*m_pLaserScannerSystem;
//! Thread timer interface
//! Pointer to laser scanner system
CListW<CMoveListElement,CMoveListElement&>
*m_pTaskList;
//! Pointer auf Tasklist
:
:
:
:
:
:
// Laser Scanner System
void
CLaserScannerSystem
:
:
:
};
//----------------------------------------------------------------------------------------------------------------------------------------
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 14 -
Data Type Ranges
C/C++ recognizes the types shown in the table below.
Type Name
Bytes
Other Names
signed,
int
*
signed int
unsigned int
*
unsigned
char,
__int8
1
signed char
short,
__int16
2
short int,
signed short int
signed,
__int32
4
signed int
__int64
8
char
unsigned char
1
1
none
Range of Values
System dependent
System dependent
–128 to 127
–32,768 to 32,767
–2,147,483,648 to 2,147,483,647
–9,223,372,036,854,775,808 to
9,223,372,036,854,775,807
–128 to 127
0 to 255
signed char
none
short int,
short
2
–32,768 to 32,767
signed short int
unsigned short
2
unsigned short int
0 to 65,535
long int,
long
4
–2,147,483,648 to 2,147,483,647
signed long int
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, 8byte 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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 15 -
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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 16 -
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__ ) )
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 17 -
Grafiken zur Benutzung als Ikone


100 DPI 256 Farben-Modus
100 DPI RGB 24 Bit
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 18 -
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
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 19 -
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
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 20 -
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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 21 -
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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 22 -
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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 23 -
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
p
pointer
Ein Zeiger zu einer Adresse.
handle
Ein Zeiger auf einen Zeiger, also äquivalent zu pp. Fast immer wird h im
Zusammenhang mit der Kommunikation mit dem Betriebssystem
benutzt.
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.
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.
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.
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.
h
rg
mp
dn
i
Bedeutung
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 24 Dennoch kann auch ein Element des Arrays rgd mit ed bezeichnet
werden, auch wenn dies in den meisten Fällen nicht zweckdienlich ist.
Eine Anzahl von Elementen, etwa in einem Array. Die Größe eines rgul
kann als cul angegeben werden.
c
count
d
Ein Unterschied zwischen zwei Variablen, meistens in einem Array.
difference Dabei sollte man nicht den Fehler machen, d mit c zu verwechseln: d
bezieht sich immer auf eine Differenz zwischen Indizes.
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.
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.
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.
gr
u
a
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.
v
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 „CGeschmack“ fest, was die Benennung betrifft (zum Beispiel l wie long für einen 32-BitIntegerwert).
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
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 25 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).
Ein einzelnes Bit. Kann meist besser mit einem ‚f‘ (flag)
bezeichnet werden.
bit
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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 26 -
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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 27 -
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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
T
- 28 Ä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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 29 -
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.
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
uuluwch
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.
Ebenfalls ein Array, dessen Elemente Verbunde oder Klassen sind. Allerdings mit
mpchgr dem Unterschied zu rggr, dass das Array von ich indiziert wird, also von positiven
Bytes.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 30 -
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.
 Dr.-Ing. habil Jörg Wollnack
Seite(n) 31
- 31 -
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
 Dr.-Ing. habil Jörg Wollnack