2013-04-19 13:38:08 +00:00
|
|
|
/****************************************************************************
|
|
|
|
**
|
2016-02-03 10:56:08 +00:00
|
|
|
** Copyright (C) 2016 The Qt Company Ltd.
|
|
|
|
** Contact: https://www.qt.io/licensing/
|
2013-04-19 13:38:08 +00:00
|
|
|
**
|
|
|
|
** This file is part of the documentation of the Qt Toolkit.
|
|
|
|
**
|
|
|
|
** $QT_BEGIN_LICENSE:FDL$
|
|
|
|
** Commercial License Usage
|
|
|
|
** Licensees holding valid commercial Qt licenses may use this file in
|
|
|
|
** accordance with the commercial license agreement provided with the
|
|
|
|
** Software or, alternatively, in accordance with the terms contained in
|
2015-02-13 13:38:30 +00:00
|
|
|
** a written agreement between you and The Qt Company. For licensing terms
|
2016-02-03 10:56:08 +00:00
|
|
|
** and conditions see https://www.qt.io/terms-conditions. For further
|
|
|
|
** information use the contact form at https://www.qt.io/contact-us.
|
2013-04-19 13:38:08 +00:00
|
|
|
**
|
|
|
|
** GNU Free Documentation License Usage
|
|
|
|
** Alternatively, this file may be used under the terms of the GNU Free
|
|
|
|
** Documentation License version 1.3 as published by the Free Software
|
|
|
|
** Foundation and appearing in the file included in the packaging of
|
2015-02-13 13:38:30 +00:00
|
|
|
** this file. Please review the following information to ensure
|
2013-04-19 13:38:08 +00:00
|
|
|
** the GNU Free Documentation License version 1.3 requirements
|
2016-02-03 10:56:08 +00:00
|
|
|
** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
|
2013-04-19 13:38:08 +00:00
|
|
|
** $QT_END_LICENSE$
|
|
|
|
**
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
/*!
|
|
|
|
\page qml-codingconventions.html
|
|
|
|
\title QML Coding Conventions
|
|
|
|
\brief code style convention
|
|
|
|
|
|
|
|
This document contains the QML coding conventions that we follow in our documentation and examples and recommend that others follow.
|
|
|
|
|
|
|
|
\section1 QML Object Declarations
|
|
|
|
|
|
|
|
Throughout our documentation and examples, \l{QML Object Attributes}{QML object attributes} are always structured in the following order:
|
|
|
|
|
|
|
|
\list
|
|
|
|
\li id
|
|
|
|
\li property declarations
|
|
|
|
\li signal declarations
|
|
|
|
\li JavaScript functions
|
|
|
|
\li object properties
|
|
|
|
\li child objects
|
|
|
|
\endlist
|
|
|
|
|
|
|
|
For better readability, we separate these different parts with an empty line.
|
|
|
|
|
|
|
|
|
|
|
|
For example, a hypothetical \e photo QML object would look like this:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/photo.qml 0
|
|
|
|
|
|
|
|
|
|
|
|
\section1 Grouped Properties
|
|
|
|
|
|
|
|
If using multiple properties from a group of properties,
|
|
|
|
consider using \e {group notation} instead of \e {dot notation} if it
|
|
|
|
improves readability.
|
|
|
|
|
|
|
|
For example, this:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/dotproperties.qml 0
|
|
|
|
|
|
|
|
could be written like this:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/dotproperties.qml 1
|
|
|
|
|
2021-07-28 11:16:45 +00:00
|
|
|
\section1 Unqualified access
|
|
|
|
|
|
|
|
In order to improve readability and performance always reference properties of parent components by their id explicitly:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/qualifiedaccess.qml 0
|
|
|
|
|
2021-07-28 11:50:01 +00:00
|
|
|
\section1 Required properties
|
|
|
|
|
|
|
|
When requiring data defined outside the component, make this explicit by using \l{Required Properties}.
|
|
|
|
Required properties must be set or else the creation of the component will fail.
|
|
|
|
These are preferable to unqualified lookups because they are more performant and allow for both
|
|
|
|
users and tooling to reason about an external property's type.
|
|
|
|
Additionally they remove assumptions that a component otherwise has to make about the environment
|
|
|
|
in which it is created.
|
|
|
|
|
2021-07-28 13:01:31 +00:00
|
|
|
\section1 Signal handlers
|
|
|
|
|
|
|
|
When handling parameters in signal handlers use functions which name them explicitly:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/signalhandler.qml 0
|
|
|
|
|
2013-04-19 13:38:08 +00:00
|
|
|
\section1 JavaScript Code
|
|
|
|
|
|
|
|
If the script is a single expression, we recommend writing it inline:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/javascript.qml 0
|
|
|
|
|
|
|
|
If the script is only a couple of lines long, we generally use a block:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/javascript.qml 1
|
|
|
|
|
|
|
|
If the script is more than a couple of lines long or can be used by different objects, we recommend creating a function and calling it like this:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/javascript.qml 2
|
|
|
|
|
|
|
|
For long scripts, we will put the functions in their own JavaScript file and import it like this:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/javascript-imports.qml 0
|
|
|
|
|
2016-10-06 08:55:03 +00:00
|
|
|
If the code is longer than one line and hence within a block,
|
|
|
|
we use semicolons to indicate the end of each statement:
|
|
|
|
|
|
|
|
\snippet qmlapp/codingconventions/javascript-semicolons.qml 0
|
|
|
|
|
2018-07-16 09:09:58 +00:00
|
|
|
\section1 Related Information
|
|
|
|
|
|
|
|
\list
|
|
|
|
\li \l {Best Practices for QML and Qt Quick}
|
|
|
|
\endlist
|
|
|
|
|
2013-04-19 13:38:08 +00:00
|
|
|
*/
|