Qt Quick Best Practices: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Use LangSwitch)
 
(9 intermediate revisions by 6 users not shown)
Line 1: Line 1:
'''English''' [[Qt Quick Best Practices Bulgarian|Български]]
[[Category:Advice]]
{{LangSwitch}}
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 <span class="caps">DONT</span>s recommended by developers while developing with Qt Quick. Please add your recommendations and help this page grow …
=== Formatting ===


=Qt Quick Best Practices=
<code>
/**
* The example component accomplishes …
*/


===Formatting===
Rectangle {
id: example


* Use 4 spaces for indentation
    // size independently from screen height
    width: 100
    height: 100
}
</code>
 
''' Use 4 spaces for indentation
* Let the { bracket be on the same line separated by 1 white space
* Let the { bracket be on the same line separated by 1 white space
* Use blank lines intelligently to separate code blocks
* Use blank lines intelligently to separate code blocks
* Use a blank line before a multi line comment easy to read
* Use a blank line before a multi line comment - easy to read


===Basics===
=== Basics ===


* Starting Qt 4.7.1, use QtQuick namespace, '''import QtQuick 1.0''' more consistent and is aimed for backward compatibility
* 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
* The .qml file name should start with an uppercase letter
* Use property alias and avoid duplicating same property within a component uses less memory
* Use property alias and avoid duplicating same property within a component - uses less memory
* Specify each property in a single line helps readability
* 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)
* 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)
* 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)
* 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
* 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)
* 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 single line comment at the end of line - one can easily miss this
* Avoid over documentation, name your variables meaningfully
* Avoid over documentation, name your variables meaningfully


===Mandatory===
=== Mandatory ===


* Each .qml file should have only one top level component
* Each .qml file should have only one top level component
Line 38: Line 50:
* Multiple properties on same line are separated by a semicolon
* Multiple properties on same line are separated by a semicolon


===Best Practices===
=== Best Practices ===


* Avoid hard coding of sizes and positions, use layouts smartly
* Avoid hard coding of sizes and positions, use layouts smartly
* Use <span class="caps">QML</span> more for UI and let Qt/C++ handle the backend, i.e. the business logic, data models
* 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++
* Trying to do too much in javascript will lead to performance issues, use Qt C++
* Use javascript as sparingly as possible
* Use javascript as sparingly as possible
* Expose the current state and the state change as properties rather than functions cleaner integration with <span class="caps">QML</span> property binding
* 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 <span class="caps">QML</span> user interface implementation and the <span class="caps">QML</span> object tree composition
* Keep C++ implementation agnostic of the QML user interface implementation and the QML object tree composition
* Avoid directly manipulating the <span class="caps">QML</span> object tree using C++. <span class="caps">QML</span> elements should “pull” data from C++ rather than C++ trying to “push” data into <span class="caps">QML</span> elements
* 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 <span class="caps">QGLW</span>idget as viewport of<br /> QDeclarativeView)
* 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())
* 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===


=== 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?'''
* Default Property: If a property has been declared as the default property, the property tag can be omitted. '''Is this a good idea?'''


Line 58: Line 69:
* If a single property has to be documented, an end of line comment could still be used
* 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.nokia.com/qml-coding-conventions.html
''For common coding conventions have also a look on'' http://doc.qt.io/qt-5/qml-codingconventions.html
 
===see also===
 
* [[Qt Quick Donts|Qt_Quick_Donts]]
 
===Categories:===


* [[:Category:Developing with Qt|Developing_with_Qt]]
=== see also ===
** [[:Category:Developing with Qt::Qt Quick|Qt_Quick]]

Latest revision as of 09:00, 11 July 2019

En Ar Bg De El Es Fa Fi Fr Hi Hu It Ja Kn Ko Ms Nl Pl Pt Ru Sq Th Tr Uk Zh

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