views:

407

answers:

7

Hello Everyone,

When I first started working with Qt, it was extremely annoying that every class has a name beginning with 'Q', but now I've got used to it.

I'm using Qt Creator, and it highlights code quite well.
However, it only highlights class names beginning with 'Q'. And it highlights everything beginning with 'Q' even if there is no such type.
It doesn't highlight custom class names.

That makes me wonder, should I also begin all my class names with 'Q'?
Or at least the reusable ones?
(I mean, those that I put in a class library, or reuse in another app.)

I've seen several places where they named their classes this way. Is it a good thing?

I found this page about Qt's naming conventions, but it doesn't deal with this question.

Also, I don't understand why Qt doesn't use namespaces.

EDIT:

Big thank you to everyone who shared his thoughts with me.

+9  A: 

Personnally, I wouldn't prefix your own classes. As Qt has its own implementation of lots of thing (string, list...) it helps to know what you're using.

The correct way would be to use namespaces. I think that Qt didn't use them because it's quite old. C++ changed a lot lately.

And generally, adapting your naming conventions according to syntax colouring is a bad idea (even if I understand that it only made you wonder about your nameming).

Tristram Gräbener
Do you know why Qt doesn't use namespaces?
Venemo
Oh... just edited my message when you asked ;)
Tristram Gräbener
Well, okay, Qt is old, but why didn't they introduced namespaces in the more recent versions?
Venemo
@Venemo: it would probably break too much existing code.
Ken Bloom
@Venemo, for starters lots of code would be broken - just three letters would spread horrors: KDE. Also, typing a Q is shorter than typing Qt::.
iconiK
@Venemo and @Tristram : Qt uses namespaces since Qt4 if you want it to. When configuring Qt before building it, you may pass the -qtnamespace parameter to wrap it all. From Qt's help : "-qtnamespace <name> Wraps all Qt library code in 'namespace <name> {...}'"
Fred
@Fred, thank you for pointing that out :)
Venemo
+17  A: 

I can't see why you would want to enforce this on your own classes at all. Let Qt do what it wants to do with its class naming convention and you do your own.

Troubadour
+1. I would also say that prefixing your own classes with Q might confuse people (or even you), making them believe some class belongs to the Qt Core while it is not.
ereOn
-1. If you're coding a Qt project, you should use Qt styles/conventions.
Inverse
@Inverse, I'd say that the Qt naming convention of appending a Q to everything was probably to make it obvious which classes belonged to Qt.
Graphics Noob
@Inverse: And what, pray tell, would you do if you are using more than one library and not just Qt. Take some sort of average?
Troubadour
+1. Qt uses the prefix to avoid collisions with client symbols (since they don't use namespaces). Naming your own symbols with their prefix just increases the chances of having a collision not to mention the confusion factor. Just use your own prefix.
Maven
+5  A: 

Use your own coding convention and standards, it doesn't have to match the library you're using. I don't think the makers of Qt are implying that you follow their style conventions.

Brian R. Bondy
You should try to match the coding standards of the API you're using. In particular, method names should have similar styles. If Qt uses interCaps to separate words in method names, you shouldn't use underscores. If Qt uses propertyName/setPropertyName, you shouldn't change that to getPropertyName/setPropertyName in your own code. (I'm sure we could get into a whole philosophy debate about what should match and what shouldn't.) However since Qt uses the Q prefix to create a namespace for its classes (a holdover from old C++ that didn't support namespaces), you shouldn't use the Q.
Ken Bloom
@ken what happens when your code uses two APIs with different styles? I agree with Brian, user generated code should use the same style.
caspin
@Caspin, in that case, try to stick conforom to whichever API is dominant (in this case that's probably Qt). In most other environments, there's a standard library that sets the tone for all development in the language (e.g. Java, where JavaBeans prefers certain conventions). In C++, where it's common to completely ignore the standard API and write your own comprehensive framework (such as Qt) in its place, you should follow the convention of the framework you're using.
Ken Bloom
@Ken - I disagree. It can be beneficial to use a completely different naming convention so that you know that when you name your stuff add_x() instead of AddX() so that you know that you're calling your own code. If your UI framework uses camel case and you use underscore then you also know that when you run into a function named with underscore to look in project docs rather than API docs. Besides, for some reason most UI libraries use conventions different from the std lib so both generally permeate code and picking one is arbitrary.
Noah Roberts
+3  A: 

I've not used Qt, but unless you're actually extending parts of Qt I would think it's a very bad idea to prefix your own classes with Qt, particularly because of the (IMO) perculiar behaviour that you're reporting from Qt Creator.

It's quite common to group related classes together with prefixes but this is quite a dated approach now. A better way to do this is using namespaces - this has the benefit of allowing scoping which a simple prefix won't give you.

If you do use namespaces, make sure that your namespace distinguishes what you're doing from the code you're writing against, e.g don't use

Qt::MyClass theClass;

use

venemo::MyClass theClass;

I'm sure you get the picture. You might also want to look at QtCreator and swap out the editor (or the entire IDE) for something that does better highlighting on C++ code.

Robin Welch
@Robin - I would very much like to use Visual Studio instead of Qt Creator, but currently Qt Creator is the only one which can build and deploy applications on Nokia devices with one click. BTW, I know what namespaces are, I just didn't understand why Qt doesn't use them by default. BTW, thanks for your answer!
Venemo
+1  A: 

Well, here's what I do. I try, and generally fail but IMHO it's worth trying anyway, to keep most of my code from knowing what UI framework I'm using. For the drawing operations of custom widgets in particular, I want them to work again later if I switch from WX to say Qt. Thus I have my own device_context of sorts that is an abstraction of what I need. Then I have a WX specific version of device_context that makes wxDC draw calls and holds a wxDC*.

You'll recognize this as the Bridge Pattern of course.

So what do I name things? Well, there's zero reason to name device_context wx_device_context since I could very well be talking to Qt. I'm trying to HIDE wx from my code, remember?

BUT! The WX specific subclass that is created on behalf of my clients IS named wx_device_context and actually resides in a wx namespace pocket created just for such purposes.

How does this apply to you? Well, if you're tempted to name a class QSomething then you're probably creating a custom something or other that's related to Qt in a specific way. Can you hide that fact through subclassing, providing an interface that clients could use that is UI library agnostic? Can the widget you are making be made in such a manner? If you ever decided you need to use some other UI library are you stuck or can you simply override some basic structures so that your custom widgets work with the new library?

The point is that your temptation to name a class QSomething is a "smell"--albeit one commonly found and generally tolerated--and you might want to consider what it indicates and what you can do, if anything, about it.

Noah Roberts
+1, Thank you for your explanation.
Venemo
+1  A: 

As to namespaces and Qt, Qt does indeed use namespaces, just not for everything. Qt runs on many systems, not all of which may have full support for namespaces. While there are current versions of Qt, that doesn't mean all the systems it runs on have updated as well. Given the amount of code out there using Qt as it stands, converting everything would be a massive undertaking; assuming all the compilers/platforms/systems Qt runs on didn't have to be worked around to move everything into namespaces.

Qt doesn't need namespaces, they have a naming scheme that works. Wanting to name your classes the way Qt does because you are using Qt is like wanting to put your classes in a Qt namespace because you are using Qt. I agree with Noah that wanting to do that is a "smell", and though generally tolerated is still not a good move. Sometimes imitation is not the most sincere form of flattery.

The Real Bill
+3  A: 

If you are considering to prefix your classes with 'Q' only to get Creator to highlight them for you, then you might want to update to a Creators master branch.

Creator used "the Q hack" since it was just to expensive to look up everything all the time. In the meantime the C++ engine was improved dramatically and these lookups can be done without slowing down the UI, so highlighting for all kinds of types was activated recently.

Unfortunately this change will not make it into Qt Creator 2.0 anymore, so you need to use either snapshots or build the whole thing yourself at this time.

Karl Napf
Okay, so 2.0 is still in beta, but this feature will not make it into the final? What a pity! Still, thank you for pointing it out!
Venemo