Qt Quick Best Practices: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Updated link)
(clean-up)
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
[[Category:Developing_with_Qt::Qt Quick]]
'''English''' [[Qt_Quick_Best_Practices_Bulgarian|Български]]
This article lists out the best practices and also the DOs and DONTs recommended by developers while developing with Qt Quick. Please add your recommendations and help this page grow …
This article lists out the best practices and also the DOs and DONTs recommended by developers while developing with Qt Quick. Please add your recommendations and help this page grow …
= Qt Quick Best Practices =


=== Formatting ===
=== Formatting ===

Revision as of 00:26, 24 March 2016

This article lists out the best practices and also the DOs and DONTs recommended by developers while developing with Qt Quick. Please add your recommendations and help this page grow …

Formatting

/**
 * The example component accomplishes …
 */

 Rectangle {
 id: example

 // size independently from screen height
 width: 100
 height: 100
 }

Use 4 spaces for indentation

  • Let the { bracket be on the same line separated by 1 white space
  • Use blank lines intelligently to separate code blocks
  • Use a blank line before a multi line comment - easy to read

Basics

  • Starting Qt 4.7.1, use QtQuick namespace, import QtQuick 1.0 - more consistent and is aimed for backward compatibility
  • The .qml file name should start with an uppercase letter
  • Use property alias and avoid duplicating same property within a component - uses less memory
  • Specify each property in a single line - helps readability
  • If you are grouping multiple properties in a single line - group logically related properties (e.g. x, y makes sense. x, color are not related)
  • Use Grouped Properties where you find logical group of properties (e.g. font)
  • Property names should begin with a lowercase letter (exception being Attached Properties)
  • Use square brackets even while assigning a single property to a list - easy to identify that its a list
  • Define signal handlers with the prefix "on" (e.g. onHover)
  • Avoid single line comment at the end of line - one can easily miss this
  • Avoid over documentation, name your variables meaningfully

Mandatory

  • Each .qml file should have only one top level component
  • Each .qml file should have at least one import
  • Component name should match the .qml file
  • A component id will be unique in that .qml file
  • The component id must not be enclosed within quotes
  • The component id must begin with a lower-case letter or underscore
  • The component id cannot contain characters other than letters, numbers and underscores
  • Specify property and value with this syntax property: value
  • Multiple properties on same line are separated by a semicolon

Best Practices

  • Avoid hard coding of sizes and positions, use layouts smartly
  • Use QML more for UI and let Qt/C++ handle the backend, i.e. the business logic, data models
  • Trying to do too much in javascript will lead to performance issues, use Qt C++
  • Use javascript as sparingly as possible
  • Expose the current state and the state change as properties rather than functions - cleaner integration with QML property binding
  • Keep C++ implementation agnostic of the QML user interface implementation and the QML object tree composition
  • Avoid directly manipulating the QML object tree using C+. QML elements should "pull" data from C+ rather than C++ trying to "push" data into QML elements
  • Use OpenGL to do any blending, scaling or rotating. (-opengl to qmlviewer or QGLWidget as viewport of

QDeclarativeView)

  • Run fullscreen rather than maximized to avoid compositing overhead (-fullscreen to qmlviewer or use showFullscreen() rather than show())

Open for discussion- add your comments directly here

  • Default Property: If a property has been declared as the default property, the property tag can be omitted. Is this a good idea?
  • Use single line comment at the end of line only in places like end of a code block Is commenting ends of block this a good style?
  • If a single property has to be documented, an end of line comment could still be used

For common coding conventions have also a look on http://doc.qt.io/qt-5/qml-codingconventions.html

see also