Member variable naming convention in Qt and the QtDN wiki



  • The are quite many naming and coding style guidelines out there for C++ and even Qt, but I stumbled over yours in the "Writing Qt Examples(WritingQtExamples)":http://developer.qt.nokia.com/wiki/WritingQtExamples that states

    bq. Member names shouldn’t start with “m_” or any other strange device. They are distracting and in 95% of cases unnecessary.

    and

    bq. If you have a conflict between a parameter name and a member variable name, solve it using “this->”:

    This is quite the opposite to many other guidelines and especially the latter one is at least totally different from the guidelines in "Qt - CodingConventions (Qt - CodingConventions)":http://qt.gitorious.org/qt/pages/CodingConventions in Qt git repository.

    As there will eventually be many examples posted in this forum, it would be nice to know which way Trolls and others would like it to be. Even better would be to have a public 'Qt way' of codingstyle guidelines, but that might be a bit too absurd...



  • Not found there anything about m_ prefix, but if you are saying about using this keyword to resolve things than please keep in mind that guidelines for "no shadowing" is for public headers, not for all code.



  • [quote author="Denis Kormalev" date="1276202125"]Not found there anything about m_ prefix[/quote]

    "WritingQtExamples":http://developer.qt.nokia.com/wiki/WritingQtExamples



  • [quote author="SABROG" date="1276233859"]
    "WritingQtExamples":http://developer.qt.nokia.com/wiki/WritingQtExamples
    [/quote]

    I meant that i haven't found it in guidelines at gitorious.



  • About the contradiction, note the caveat at the top of the WritingQtExamples page. I read the advice roughly as "In general, try to avoid ambigious naming - even though there are tricks to disambiguate it to the compiler, it will probably still make your code more fragile to maintain and harder to read. If, however, after using your good sense, you find yourself in a situation where you think the naming really should be as this, it is not common Qt practice to avoid the name clash with prefixes like m_; rather the this->x = x construct is recommended."

    In general, when wondering about coding conventions, my advice would be to look around in the Qt source code and try to see what the common practice is. In a constructive way, of course; just because one can find one instance of a special construct somewhere among the 3 million lines does not mean that it is "blessed" or considered best practice ;-)

    The documents mentioned in this thread are a kickstart, this one is also recommended: "Qt Api Design Principles":http://qt.gitorious.org/qt/pages/ApiDesignPrinciples



  • I use "m_" prefix only in private section for variables-members of class to avoid conflict between names of private variable and function-getter for it. For example, I have class with variable QString name; and getter for it - QString name(). There is a conflict and I use "m_" to resolve it. No sense of using "m_" in public section. If you have private class for private data (Pimpl paradigm) - don't use "m_" also.



  • I agree with joe.skb7

    If you are following Java coding standards (getters begin with get - getSomething()) then members can really be named without some kind of prefix, but here it is awkward. (having "this->" before everything produces a lot more visual clutter than m_ or just _)

    If you are writing a library and are concerned about the binary compatibility, then you could go for the d-ptr pattern (like Qt does). This way all private members would be in the Private class instead of the main one and you'd access them as d->name or similar.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.