Results 1 to 5 of 5

Thread: ClanLib 0.9 Coding Standards

  1. #1
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default ClanLib 0.9 Coding Standards

    I really like the coding standards in ClanLib. (I have used very similar standards at work for the past 11 years).

    There is one exception to this: Member variables in classes

    Currently, the variables can be anything. This conflicts with local functions variables names.

    For Example
    Code:
    class MyClass
    {
    public:
       void Test();
       int window;
    }
    
    void MyClass::Test()
    {
     ...
     int window = TempWindow();
    ...
     window = NewWindow();
     ...
    }
    The local variable is modified instead of the class member variable.

    At work, I use the "m_" prefix for class member variables, with the first letter in Caps.

    For example "m_Window"

    Any thoughts?

    (Also CODING_STYLE file needs updating to reflect doxygen style comments)

  2. #2
    Administrator Seth's Avatar
    Join Date
    Jul 2002
    Location
    Japan
    Posts
    5,343

    Default

    Agreed.

    Not a big deal, but I vote for the the m_ prefix because I use it with my work projects also.

    Although for me I only use caps to make words more readable:

    Code:
    int m_window;
    bool m_bWindow;
    char * m_pWindowName;
    string m_windowName;
    Seth A. Robinson
    Robinson Technologies

  3. #3
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Actually, i use that exact method myself!!! Spooky!

  4. #4
    Lesser Knight
    Join Date
    Aug 2008
    Location
    Folsom, California USA
    Posts
    37

    Default

    I've used the 'm_' prefix as well in the past. Since I started using Python, I've come to prefer their convention of just a leading underscore to signify "private" members. I also use it for "module-scope" globals and types to signify that they aren't intended for external use.

    As for decorating pointer variables, I think its less important to know whether something *is* a pointer (the compiler will keep that straight) than to know what is the "ownership" of the pointer in the current context? Is it a "smart" pointer, is it "borrowed" and so should not be deleted, or is it "owned" and the current scope should delete it?

    --- Kevin

  5. #5
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    I really do not like the m_ prefix, since I consider it redundant information except in situations where the code needs a clean up. I do agree that without the prefix there are occasional situations where a function name might clash with a variable, but it is fairly rare and never annoyed me personally when it happens.

    There are three things in the current convention that annoy me a bit:

    1. I know' #pragma once' is non-standard but all the compilers we use support it, so the headers would look nicer if we used that instead.
    2. The current doxygen doc markup defines the clanGroup stuff in a way that makes it appear as garbage when you use the normal HTML output. I think if the \xml tag is used, this could probably be avoided.
    3. Excessive use of the 'return' keyword. I once figured it would make code easier to read, but it seems to do the exact opposite.

Similar Threads

  1. Replies: 7
    Last Post: 08-26-2008, 09:57 PM
  2. Installing ClanLib 0.8 and ClanLib 0.9 on linux
    By rombust in forum Official ClanLib SDK Forums
    Replies: 4
    Last Post: 07-15-2008, 09:51 AM

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •