Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Behind the Scenes
  3. Qt.io webservices
  4. Member variable naming convention in Qt and the QtDN wiki

Member variable naming convention in Qt and the QtDN wiki

Scheduled Pinned Locked Moved Qt.io webservices
7 Posts 6 Posters 11.8k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    kleimola
    wrote on 10 Jun 2010, 18:08 last edited by
    #1

    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...

    >> Johannes <<

    1 Reply Last reply
    0
    • D Offline
      D Offline
      DenisKormalev
      wrote on 10 Jun 2010, 20:35 last edited by
      #2

      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.

      1 Reply Last reply
      0
      • S Offline
        S Offline
        sabrog
        wrote on 11 Jun 2010, 05:24 last edited by
        #3

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

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

        QT - Apple QuickTime
        Qt - Nokia's Qt Development Frameworks
        Apple is a competitor of Nokia, so QT != Qt

        1 Reply Last reply
        0
        • D Offline
          D Offline
          DenisKormalev
          wrote on 11 Jun 2010, 08:50 last edited by
          #4

          [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.

          1 Reply Last reply
          0
          • A Offline
            A Offline
            aavit
            wrote on 11 Jun 2010, 10:48 last edited by
            #5

            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

            1 Reply Last reply
            0
            • J Offline
              J Offline
              joe.skb7
              wrote on 7 Aug 2010, 11:09 last edited by
              #6

              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.

              1 Reply Last reply
              0
              • I Offline
                I Offline
                ivan
                wrote on 7 Aug 2010, 13:13 last edited by
                #7

                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.

                Ivan Čukić | ivan.cukic(at)kde.org | KDE e.V.
                Qt Ambassador (from the old Nokia days)

                1 Reply Last reply
                0

                • Login

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Users
                • Groups
                • Search
                • Get Qt Extensions
                • Unsolved