Code critique request



  • Hello Everyone.

    As a learning experience I am writing a little application which will be the equivalent of SQLiteman or PGAdmin3 but for the MongoDB database software. Currently there is very little, I am working on what will become the tree navigation for the servers / databases / collections etc. but it is taking shape so I think now is a good time to see if I am going wildly off-track or not.

    First a bit of background: I studied C++ in university 9 years ago and haven't used it until last week when I started this so, with regards to c++ I am as rusty as a victorian doornail. This is also my first project using the Qt framework.

    If anyone has the time and inclination I would appreciate any feedback you can give including everything from code, design, use of Qt, documentation etc. You name it, it is a target.

    The source-code can be found at: "https://github.com/rurounijones/asnme":https://github.com/rurounijones/asnme

    Known weak-points/bugs are:

    • VERY little / no error handling yet, especially regarding the host field when adding a server (It should accept an IP/ FQDN, any validation tips on this one?)
    • Removing servers from the explorer list is buggy.
    • All the .h and .ccp files are lumped together in the main directory. Any best practices on sorting these into folders would be appreciated! (Group by function? Widget? Filetype?)

    I am currently using QT Creator .ui files for the widgets but to be honest I am not sure if it is the best way, GUI editing is nice and everything but having chunks of code hidden away from the .h and .ccp file just seems like it is going to cause confusion later. Opinions?

    Documentation is using doxygen but I haven't included them in the repository yet due to having different versions installed on different machines I use for coding.

    If you want to compile it you need the MongoDB C++ driver; information on this can be found in the README.

    Many thanks

    RJ



  • Hi,

    some general things for your general questions :-)
    But they are only my opinion :-)

    I would goup the files in folders for layers or for functionality (e.g. all DB things, all UI things, ...)

    I like to create the UI by hand so I code it completly, don't use .ui files



  • A small counterpoint then:
    I do like to use .ui files. I find it convenient to be able to design and adapt my UI's in a drag & drop way, without coding it all by hand. It is easy to combine that with hand coding where needed, both in terms of including completely hand-coded widgets into a Qt Designer created UI, and in terms of adapting a Designer created UI dynamically from code.

    I do agree on the grouping of files. Per logical cluster of code, I use a src directory for my .h and my .cpp files, a ui directory for my .ui files, and a resources directory for my .qrc files (and under that, directories with the actual contents of those). At the top of those, you'll find the .pro or .pri file(s) for that component.



  • I also like to use ui files generated by designer where possible. I just find it quicker this way, especially if you need to change a lot of layouts. As Andre said you can still include hand-crafted widgets where needed.

    Are you using the modelview architecture or are you using the widget-based convenience classes such as QListWidget?



  • At the moment I am sub-classing QStandardItemModel and QStandardItem to create the Server->Database->Collection (Table in SQL speak) hierarchy and using a QTreeView to display everything.

    Whether I am doing it properly is another question entirely which was one of the reasons I posted this ;)



  • That sounds reasonable to me. If your models get large or QStandardItem becomes too much of a hassle to work with then it is time to consider sub-classing your own model. It sounds as if you have this aspect in hand though.



  • Using a QStandardItemModel is an option, of course. It's just that they are not very suitable for dymanic models (tables that get added behind your back) or can become hard to maintain for bigger models, but they provide a good starting point.



  • Being new to Qt and having forgotten 90% of my C++ I went with the path of least resistance at the moment regarding the models :)

    I will probably have to change something later but for the moment it is working for me.

    I have just about finished reorganising the files if anyone wants to comment.


Log in to reply
 

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