Qt Quick Best Practices/bg

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

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

Тази статия съдържа списък от най-добрите практики, а също и съвети от разработчиците, какво ДА и какво ДА НЕ правите, докато създавате приложения с Qt Quick. Моля, добавяйте вашите препоръки и помогнете на тази страница да расте …

Най-добри практики в Qt Quick

Форматиране

/**
 * Този компонент предоставя …
 */

 Rectangle {
 id: example

 // размер независим от височината на екрана
 width: 100
 height: 100
 }

Използвайте 4 места за идентация

• Слагайте { на същият ред като елемента/оператора, отделена с 1 празно място
• Използвайте празни редове интелигентно за да отделяте блоковете код
• Използвайте един празен ред преди многоредов коментар - така става по-лесен за четене

Основни съвети

• От Qt 4.7.1 използвайте именното пространство QtQuick, import QtQuick 1.0 - дава възможност за обратна съвместимост
• Името на .qml файла трябва да започва с главна буква
• Използвайте property alias и избягвайте дублирането свойства в компонента - използва се по-малко памет
• Използвайте всяко свойство на отделен ред - помага за четимостта на кода
• Ако групирате няколко свойства на един ред, групирайте ги по смисъл (например. x, y е логично и смислено, докато x, color - няма)
• Използвайте групирани от свойства, където срещнете логически групи от свойства (например font)
• Имената на свойствата трябва да започват с малка буква (с изключение на Прикрепените свойства)
• Използвайте квадратни скоби, дори когато присвоявате само една стойност на списък - така после по-лесно се разбира, че това е списък
• Дефинирайте обработката на сигнали с префикс "on" (например onHover)
• Избягвайте коментари на в края на реда - човек лесно може да ги пропуснете
• Избягвайте претрупването на кода с коментари, именувайте променливите си със значещи имена

Задължителни изисквания към компонентите

• Всеки .qml файл трябва да има само един компонент на най-горно ниво
• Всеки .qml файл трябва да има поне един import
• Името на компонента трябва да съвпада с името на .qml файла
• Идентификатора на компонента трябва да е уникален за .qml файла
• Идентификатора на компонента не трябва да бъде в кавички
• Идентификатора на компонента трябва да започва с малка буква или долна черта
• Идентификатора на компонента не трябва да съдържа символи различни от букви, цифри долна черта
• Специфицирайте свойство и стойност с property: value
• Множество свойства на един ред се отделят със точка и запетая

Добри практики

• Избягвайте закодираните с константи размери и позиции, използвайте автоматичното позициониране интелигентно
• Използвайте QML за интерфейса и оставете на Qt/C++ да се занимава с изчисленията като бизнес логика и модели с данни
• Опитите да направите всичко с JavaScript ще доведе то проблеми със производителността, използвайте Qt C++
• Използвайте JavaScript колкото е възможно по-пестеливо
• Излагайте текущото състояние и промените в него като свойства вместо като функции - това води до по-ясна интеграция с обвързването на свойствата в QML
• Дръжте C++ имплементацията независима от QML интерфейса и от обектното дърво в QML
• Избягвайте директно да манипулирате обектното дърво в QML през C+. QML елементите трябва да "дърпат" данни от C, а не C+ да се мъчи да вкара данни в QML.
• Използвайте OpenGL за смесване, преоразмеряване или завъртане. (-opengl като опция на qmlviewer или QGLWidget в комбинация с

QDeclarativeView)

• Стартирайте приложението на цял екран вместо максимизирано, за да избегнете натоварване при композирането. (_-fullscreen_ като опция на qmlviewer или използвайте showFullscreen() вместо show())

Отворено за дискусия- добавете вашите коментари тук

• Подразбиращи се свойства: Ако свойство е декларирано като подразбиращо се, запазената дума property може да се изпусне. Това добра идея ли е?

• Използвайте коментарите на края на реда само за да коментирате край на блок. Това добър стил на писане ли е?

• Ако отделно свойство трябва да се документира, коментар на края на реда е допустим

Основните конвенции при писането на код можете да намерите тук