How To Produce Neat Code
-
Hello everyone,
I am new to Qt and I really want to produce a clean and neat code which will be easy to understand for others and reusable.
In order to find the proper way to develop a Qt project, I created a MainWindow with 2 PushButtons : the first one will open a FileDialog and will print in a pop-up the path of the chosen file, the other one will quit the program.
I did it in two different and seperate ways :
-
First I hand coded everthing, created my own classes which inherite from Qt classes. Then I create my widgets in constructors etc.
-
Second I did everything via the Designer but then there is almost no code at all but an empty MainWindow class. Everything is in the .ui file in form of Xml.
Which way is better ?
Could you give me some advise ?
Thank you a lot !
-
-
Hi, welcome to devnet.
As usually - there is no "better". It's a matter of taste, scale and amount of code/ui balance. Usually, when you setup your ui class you put the initialization in some method e.g.
setupUi()and call it in the constructor. That's what uic(the ui compiler) does too so whethersetupUiis generated or handcrafted is up to you and could be a decision on a class by class basis.Some things to take into account when deciding:
- is everything you want to do supported by the designer? To name a couple of things that aren't - embedding QMainWindow in another widget or adding a toolbar to a non-mainwindow layout.
- do you need to see exactly what the outcome will be? For example if you have a global stylesheet applied to the application object you won't see it in the individual widgets in the designer
- How much of ui customization do you need e.g. stylesheets, margin adjustments, properties changed etc. Usually the more of it the easier it is to do in the designer, as you get the instant visual feedback and testability
- what's the balance of ui code and app logic? If the logic is heavy you probably don't want to obscure it in the code by ui setup code
- there's nothing wrong in almost empty classes. In line with Single Responsibility Principle a class should focus on one thing and not accumulate crust. If its sole role is to show a widget with minor customization then so be it.
-
Thank you for your answer. Nevertheless, I am still lost and don't know how to start my project.
-
Well it's a vague description of a problem but let me try to spill some thoughts that might help you. I know that when you start a new project it's tempting to just sit and start coding but take a while to (roughly) plan the thing first.
First decide on one phrase that will define your app. Don't focus on individual functionalities. Just something like "a music player", "a database engine"or "a game" will do.
Next, based on that, list the minimum necessary functionalities that match that description. Again - don't go into details e.g. what color it will havem what for loop you need to write in what class or where a particular button will be placed. That's not important yet. Things like "streaming music", "read/write xml file", "prompt user for credentials", "interpret gamepad input" etc.For these start to split them into functionalities that you can encapsulate into classes. A good rule of thumb is that a class name should describe the whole class functionality. If you need to use "and" to do that, e.g "XmlReaderAndParser" or "LoginDialogAndCredentialsValidator" , the class is too big and you should split it.
Now you should have a fairly long list of classes. Go through them and see which are ui classes, which are app logic ones and which are helpers. Try to create a dependency diagram for them i.e. which class uses which. You should try to make as little connection lines as possible. You should try to have as close to 0 lines connecting ui classes with logic classes as possible.
Now you can start coding. Again - a little against the first impulse - start with the utilities, not the big functionalities. Write proper tests and make sure the little blocks work. Building the classes up the hierarchy should seem like joining lego bricks. Writing test cases for them should also be trivial this way.
My feeling is you focused on a detail and you can't see the forest for the trees. If you start the process this way, the decision whether to use a designer or not will become minor. Designer and code generation is a convenience feature and it does not (or should not) influence the general design of your app. It basically does the single "setupUi" method for you. If it can cut some coding time of yours - great, use it. If you need to spend more time because you decided to use it - just ditch it, no big deal.
