Property Ordering

• id first
• bindings to properties, starting with the oldest ancestor base type and ending with the closest base type
• property declarations
• signal handlers
• attached properties
• function declarations
• large property assignments (like model and delegate)
• child items

I think property assignments should be as close as possible. When a file gets bigger, it gets hard to tell whose property I'm assigning to because it's hard to discern the indentation and which item that level refers to.

I find that code gets harder to read when you go from assignments to functions and to assignments again.

Personally I find it very jarring to declare new properties before existing ones are assigned to. :D

And the way I see it it lets me know at the top that these are the properties and I can assign to them like I would with the built-in properties. And also it's part of the interface, and when I look at a QML file, I see them first and I know what properties are available.

You could argue the functions are also part of the interface and they should be at the top, but I try to use as few functions as possible. And with functions, I see them as things that operate on the entirety of the component. So, when they are down below I mentally find it easy to understand the relationship to the object it's declared in.

Animations

This is not a good argument for bunching up code onto one line. I know there are people (Qt developers, too) who will disagree with me on this, but I think any more than 2 property bindings > on one line is too much. I think it makes it less readable, actually.

I agree with you. When I initially wrote this, I was fine with it. But as time went on, and I worked more with QML and on bigger projects, multi line is almost always better than single line. I usually find it acceptable for one line if it doesn't exceed 80 characters.

Giving Components IDs

Sorry, but is not something I would consider a best practice. Names should be descriptive, and if that means making them long, so be it. This becomes so important when you have to maintain an existing codebase; if a variable is not well-named, it makes everything just that little bit harder. A good IDE solves the problem of typing with auto-completion.

You are right. I no longer follow that practice. I should have updated it. I did not know better when I wrote this.

Import Statements

I don't like this advice, because it conflicts with the idea of keeping QML files as small and self-contained as possible. If users follow this advice, they will end up with gigantic QML files. As for the performance side of it, I have no idea if it's true or not, but that's something Qt should aim to fix if it's an issue, rather than advocate for less imports. :)

When I wrote this, I did a profiling and initially QML imports were taking a while. I believe this was with 5.11. So I should do it again to confirm If that's the case or not. Also, knowing that some people use QML for embedded development as well, I wanted to point out some cases that might affect performance. I think it should be more clear so that people don't go the premature optimization way.

Item 2: Bindings

The premise here is wrong, I think.

You are absolutely right. That section needs to be removed. I can maybe change it so that it can say don't repeatedly update a property that other's are bound to. So instead of;

for (let i = 0; i < 100; i++) {
    root.someProperty += i
}

They do:

let tmp = root.someProperty
for (let i = 0; i < 100; i++) {
    tmp += i
}

root.someProperty = tmp

Thanks a lot, Mitch! I'm looking forward to more of your feedback.

from qml-coding-guide.