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.
EDIT 2:
It seems that the newer versions of Qt Creator now also highlig开发者_运维技巧ht the class names not beginning with 'Q'. Nice!
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.
Personnally, I wouldn't prefix my 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).
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.
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.
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.
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.
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.
精彩评论