Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
CQG / Задание1 / HDS_VCPP_Programming Rules.doc
Скачиваний:
9
Добавлен:
16.04.2013
Размер:
327.68 Кб
Скачать

Assigning Names

Rule 17.The names of abstract data types, structures, typedefs, enumerated types, and functions must begin with an uppercase letter.

Rule 18.In names consisting of more than one word, the words are written together and each word must begin with an uppercase letter.

Rule 19.A class must be prefixed with a ‘C’ unless it is an interface. All interfaces must be prefixed with an ‘I’.

Rule 20.All enumerated types must be prefixed with an ‘E’.

Rule 21.All non-static member data of a class must be prefixed with an ‘m_’. All global variables must be prefixed with a ‘g_’ and static variables (including static class members) – with an ‘s_’.

Rule 22.Do not use an identifier that begins with one or two underscores (‘_’ or ‘__’).

Rule 23.A name must appear directly after its prefix.

Rule 24.A name must be separated from its suffix using an underscore (‘_’).

Rule 25.Do not use identifiers that differ only by the use of uppercase and lowercase letters.

Rule 26. All identifiers of types listed inAppendix Amust use Hungarian notation. The name following a Hungarian notation prefix must begin with an uppercase letter.

Rec. 11.All global visible classes, enumeration types, type definitions, functions (except member functions), constants, and variables in a class library should be declared in a declarative region using the keywordnamespace. If the compiler does not support namespaces, the identifiers should begin with a prefix that is unique for the library.

Rec. 12.Names should not include abbreviations that are not generally accepted.

Rec. 13.A variable with a large scope should have a long name.

Rec. 14.Choose variable names that suggest the usage.

Rec. 15.Write code in a way that makes it easy to change the prefix for global identifiers.

Rec. 16.Encapsulate global variables, constants, and functions in classes.

In this chapter, it is important to distinguish between identifiers and names. The name is the part of an identifier that shows its meaning. An identifier consists of a prefix, a name, and a suffix (in that order). The prefix and the suffix are optional. A suffix is only used by tools that generate C++ code, to avoid name collisions with user-written C++ code and is not given further consideration here.

It is recommended that identifiers should not be extremely long, to reduce the risk for name collisions when using tools that truncate long identifiers.

The use of two underscores (‘__’) in identifiers is reserved for the compiler’s internal use according to the ANSI-C standard. Underscores (‘_’) are often used in names of library functions (such as _mainand_exit). In order to avoid collisions, do not begin an identifier with an underscore.

One rule of thumb is that a name that cannot be pronounced is a bad name. A long name is normally better than a short, cryptic name. Abbreviations can always be misunderstood. Global variables, functions and constants should have long enough names to avoid name conflicts, but not too long. See Examples 10-12.

Classes should be named so that object..functionis easy to read and appears to be logical.

Hungarian notation was designed to provide a shorthand method for identifying the contents of a data item. This means a system of special symbols for using when naming variables. This makes it possible to know right away what type of variable is used, when viewing a program. See Appendix Afor more information.

It is impossible to suggest prefixes for all classes that may be used by a programmer. Anyway, you should prefix instances of all common classes such as STL classes. For instance, use ‘str’ for CString and ‘rg’, ‘v’, ‘list’, ‘map’ for container classes. Try to use such prefixes that show what class a variable belongs to.

See also Appendix Bfor prefixes used by MS Visual C++ in resource files.

There are many class libraries available for purchase and there may be tens of thousands of classes in a large project! Hence, it is important to be careful that name collisions do not occur. One way of preventing collisions is to use namespaces or have strict rules for assigning names to globally visible objects (such as use of a prefix). In this way, classes from several different class libraries may be used at the same time.

Names for the following types of objects should be prefixed if namespaces are not used:

  • type names (classes, typedefs, enums, structs, unions, etc.);

  • global variables and constants;

  • function names (not member functions names).

C-style functions (declared as extern "C") and preprocessor macros (#define) should always be prefixed. SeeExample 13.

If you intend to use a file with a compiler that does not support namespaces, it may be helpful to allow users to turn off the namespace declaration (seeExample 14).