GOOD point regarding the include-guards! I wouldn't have thought of that, wonder when the next compile time error will bite me in my other projects because of this ;)
About private members: _if_ I ever used some special naming convention for their names, it used to be m_foo but _foo is one letter less typing ;) Either way I think it's up to you to decide that since it's really just a matter of taste I guess and after all this project is your baby :) - unless there is some rule that variables starting with underscores are reserved for gcc's or libstdc++'s implementation or whatever. But this kind of refactoring (renaming variables) is easily done with QtCreator so whenever I feel like it I will throw in some coding style commit where a few classes are updated (I think it won't be all classes in one commit, refactorings get boring and I will try to keep my activity confined to Gui-related classes). I'm not sure about private member functions, I've never seen any special naming for those as far as I can remember. But again: you're the boss. One thing that hasn't been mentioned so far comes to my mind: Order of includes: file Gui/SomeWidget.cpp: //"system" headers #include<iostream> //Qt headers #include <QtBla> //header for the class implemented here #include "SomeWidget.h" // (1) //project headers #include "Gui/Window.h" // (2) ...I don't know why but the part of a .cpp where all headers are included tends to turn out the most ugly in my projects so I really like policies like "order Qt includes alphabetically"... About (1): when writing a .cpp it comes naturally to #include the corresponding .h right before all other project headers - should this be a policy? About (2): even though SomeWidget.cpp is in the same folder as Window.h I tend to explicitly write "Gui/Window.h" - gives a little more structure to this part of the file. Btw: I read some time ago that obviously it is best practice to explicitly specify the Qt-Module when including headers since this leads (lead? not sure if this is still relevant) to build problems on Mac - i.e. #include <QtGui/QWidget> instead of just #include <QWidget> - that never bothered me though as I didn't (have to) care about my app being portable to Mac before... Ok, I'll stop here, this mail is already long enough :) Cheers, Thomas
