• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Overview

            Applications on Symbian OS use a standard set of conventions to name their classes, structs, variables, functions, macros, enumerations, and constants. This topic explains the meaning of these conventions.

             

            Class names 

            Most class names are formed with a prefix letter C, T, R, or M. Briefly, the meaning of these is as follows: 

          1. C: heap-allocated classes, that are derived from a base class CBase

          2. T: value classes, that do not own any external object

          3. R: resource classes, that contain handles to a real resource which is maintained elsewhere

          4. M: interface classes, that define abstract protocol definitions that are implemented by derived classes

            Classes that consist solely of static member functions have no prefix letter. Beyond the prefix, the class name is usually a noun that indicates the purpose of the class.


            Struct names

            Structure types are considered as similar to T classes, as they should not own external objects, and are normally given names beginning with T (although some begin with S).


            Variable names

            Member variables names begin with i, e.g. iMember. This makes it easy to check that certain cleanup-related rules are being obeyed. Arguments names begin with a, e.g. aControl or aIndex. Local variables names have no initial letter. Global variables are usually avoided, but when used, their names begin with a capital letter.

            Symbian OS does not use Hungarian or any notation which attempts to include the variable type in its name: such notations are ugly, and become impossible to manage when there are several hundred classes in the system. They are irrelevant anyway: functions are usually so short that it is easy to see the types of variables defined in them, and class browsers provide a quick way to find the types of class members.


            Function names

            Functions names indicate what they do. They are usually verbs. One exception is getter functions: for a function which returns the value of a member variable, the function name is usually the name of the variable, without the leading i:

            inline RWindow& Window() const { return iWindow; };

            A corresponding setter function would include the word Set, e.g. SetWindow().

            To terminate functions because of error conditions, Symbian OS does not use standard C++ exception handling, but its own system called leaving (see Cleanup Support Overview). Any function that might leave has a name ending in ...L(). This makes the fundamental process of checking for errors easier. The new (ELeave) function might also leave. The fundamental leaving function is User::Leave(). Any function that contains any of these, and does not trap them, might itself leave, and should be coded with a trailing L in its name. If a function calls another which might leave, then its name should have the L suffix also.

            Associated with the leaving mechanism, is the cleanup stack, which allows memory allocated on the heap to be recovered when a leave occurs. An allocation or construction function which places data on the cleanup stack ends with ...LC(). For instance, many new, PushL(), ConstructL() sequences are encapsulated in a NewLC() function:

            CS* s=CS::NewLC(p1, p2);

            This allocates the object, initialises it, and leaves it on the cleanup stack. This process may leave (if only through the PushL()!), so such functions always include an L, and are therefore ...LC().

            A function which takes ownership of its object and destroys it has a name ending in ...D(). An example is the UI framework dialog protocol:

            CEikDialog* dialog=new (ELeave) CBossSettingsDialog;
            if (dialog->ExecuteLD(R_BOSS_SETTINGS_DIALOG))
                {
                // handle successful settings
                }

            The ExecuteLD() function includes second-phase construction, execution of the dialog and then destruction.


            Macro names

            Macro names are all capitalised, with underscores to separates words.


            Enumeration names

            Enumerations are named as follows:

            • as enumerations are types, they have the T prefix
            • enumeration members have the prefix E
            • type and members should have a meaningful, unambiguous name

            Enumerations should be scoped within the relevant class, so as not to pollute the global name space.

            An example of the declaration and use of an enumeration is as follows:

            class TDemo
                {
            public:
                enum TShape {EShapeRound, EShapeSquare};
                };

            TDemo::TShape shape=TDemo::EShapeSquare;



            Constant names

            Names of constants have a prefix K. For example,

            const TInt KMaxNameLength=0x20;

          5. Feedback

            # re: Name Conventions for Applications on Symbian OS  回復  更多評論   

            2008-04-27 14:59 by cheney
            支持!

            posts - 1, comments - 5, trackbacks - 0, articles - 2

            Copyright © cheney

            久久精品a亚洲国产v高清不卡| 久久人爽人人爽人人片AV| 国产情侣久久久久aⅴ免费| 韩国无遮挡三级久久| 亚洲国产综合久久天堂| 精品国产乱码久久久久久1区2区 | 久久综合九色综合欧美就去吻| 一级a性色生活片久久无| 久久久久人妻一区精品性色av| 国产精品日韩欧美久久综合| 亚洲色欲久久久综合网| 久久久久亚洲AV无码去区首| 日韩久久久久久中文人妻| 欧美粉嫩小泬久久久久久久 | 亚洲国产精品人久久| 国产亚洲精品自在久久| 污污内射久久一区二区欧美日韩| 99久久精品国产一区二区| 亚洲国产精品无码久久久蜜芽| 99蜜桃臀久久久欧美精品网站 | 久久婷婷五月综合成人D啪| 久久久久亚洲AV无码麻豆| 欧美日韩精品久久久免费观看| 久久久WWW成人免费精品| 久久久青草青青国产亚洲免观| 久久久精品一区二区三区| 久久精品中文字幕久久| 国产美女久久久| WWW婷婷AV久久久影片| 精品久久久无码人妻中文字幕豆芽| 中文无码久久精品| 日韩精品久久久肉伦网站| 人妻久久久一区二区三区| 新狼窝色AV性久久久久久| 久久久亚洲欧洲日产国码aⅴ | 久久国产乱子精品免费女| 9久久9久久精品| 少妇久久久久久被弄到高潮| 久久综合五月丁香久久激情| 青青草国产97免久久费观看| 午夜视频久久久久一区|