Post on 27-Aug-2019
transcript
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