Naming Convention

We quietly do the programming just for the sake of completing the assigned task. And in that process we just ignore few basic steps to follow which can help us to resolve future coming problems of the same task in comparatively less time. Naming Convention is the one of the step for that. In simple language, Naming Convention refers to a (predefined) technique for assigning names to variables, functions, classes, structures, files, projects, etc.

Each class (which is not interface) name should start by letter C (letter S for structure). Then followed by the company reserved letter, like R for RTPL. After that it should have actual example, name of the demuxer class will be CRDemuxer. In case of interface (class with all pure virtual functions, no implementation, no member variables),

class name. For

class name should start with letter I instead of C (or S). For example, interface PSI-SI Table Parser
will be named as IRTableParser.

Each class or structure must be declared and defined in separate files, and their file

names should be

the name of class or structure itself. If a file doesnt represent just a class or structure, then file name should be the task performed in that file.

File name for a class (which is not interface) should be the same as that of the class name except the
first letter C (S for structure). For example, file name for a class named as CRDemuxer will be RDemuxer.h and RDemuxer.cpp In case of interface, file name should be same as that of class name. For example, file name for a class named as IRTableParser will be IRTableParser.h

Header file format should be as follows (for example CRPATTableData)

#ifndef R_PAT_TABLE_DATA_H #define R_PAT_TABLE_DATA_H class CRPATTableData <= this is header file macro to avoid compilation error <= all letters of header file macro should be CAPITAL

{ }; #endif //R_PAT_TABLE_DATA_H For interface for example IRTableParser, header file macro will be IR_TABLE_PARSER_H

Variable names

must, without exception, indicate the function of that variable to easily

comprehend the purpose of a variable. Variable names should never be generic, e.g. variables i, j, and k for loop counters, names such as temp, tmp, foo, and bar for temporary variables, etc. Variable names should not be reused within the same scope.

Adopting

capitalization/formatting

scheme

Delimiter-separated

words

(nonalphanumeric character), Letter-case separated words (medial capitalization / CamelCase) Does the scheme effectively separate words (in variable name)? Is it easy to read? It can be confusing, for example, to type settextextended, not to mention confusing to read. setTextExtended, SetTextExtended or set_text_extended are far easier to read. It is wise to use a longer but more readable name versus a shorter name with a difficult to remember acronym or abbreviation. If a the page counter is sometime referred to as Page_Counter, PgCntr, PageCntr, or PageCtr then a future maintenance programmer may have a very difficult time remembering which abbreviation is used for any given variable name. Problems arise, however, when a different programmer works on the project, or when the same programmer returns after a hiatus it is also quite helpful in making sure that variable (and function) declarations are correct. For example a variable apnode would be declared as NODE *apnode[10]; the NODE corresponds to the base type node, the * corresponds to the prefix p, and the [] corresponds to the prefix a. The basic premise is that it is always easier to read and modify one's own code than that written by someone else. Therefore, if everyone writes in the same manner, it will be equally easy to read and modify code written by anyone. Since one of the key parts of writing code is the names used, if everyone uses the same names, everyone's code will be similar, and therefore easy to read and modify. Case should not be used to differentiate between variables, so Foo is different from foo.

All variable names are composed of four elements: scope, prefixes, base type, and qualifiers. Not all elements are present in all variable names; the only part that is always present is the base type. The

base type should not be confused with the types supported directly by the programming language. For example, the base type stk could refer to a class implementation of a stack; a co could be a value specifying a color. tags should be short (typically two or three letters) and somewhat mnemonic. all tags used in a given application be clearly documented.

there are a few standard ones that appear in many different applications; synonyms for these types should never be used b ch s sz psz p a r Boolean or bool character string character array / zero terminated string character pointer pointer array reference | |---| int**& rppiNum;

(Use just the a prefix for statically declared arrays, and use the pa prefix for dynamically allocated arrays and arrays received as function parameters.) g_ m_ global member

s_ static (variables that are available to multiple functions all within the same file, but not available to functions in other files (essentially a global variable, but private to one file) NOTHING FOR CONSTANT VARIABLE NOTHING FOR LOCAL VARIABLE qs / qstr fn i QString

function integer |

n l f d e vec lst map stk que deq

short long float double enum vector list map stack queue dequeue

|---|

unsigned

sav

a temporary saved value

Avoid using names that describe what happened to set a state or what should happen as a result. For example, a flag set when part of a window has become newly exposed should be fDirty, not fNeedsUpdate

When a variable of that structure type is declared, it should take the same type name, with all letters lowercase (e.g. DATE date;). The same rules apply to classes and unions.

capitalizing the first letter of the function name (all variable names begin with a lowercase type. Each word should be capitalized If the function operates on (modifies) an object, the object's type should be included in the name of the function using the form VerbType, where "Verb" describes the operation performed. Functions like this are commonly used when programming in a class-like (or object-oriented) manner; typically the first

parameter to such a function is a pointer to the object to be manipulated. For example, you could have functions like InitCa(pca, ...), DrawDd(pdd, ...), etc. If the function is defined as static (it can be called only from functions within its file), an underscore (_) should be placed at the beginning of the name

[RTPLs documented variable tags] b e i n l f d ch s sz psz p a r g_ m_ Boolean or bool enum integer short long float double character string character array / zero terminated string character pointer pointer array reference global member | |---| u unsigned

s_ static (variables that are available to multiple functions all within the same file, but not available to functions in other files (essentially a global variable, but private to one file) NOTHING FOR CONSTANT VARIABLE

NOTHING FOR LOCAL VARIABLE vec lst map stk que deq sav vector list map stack queue dequeue a temporary saved value