Български English

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

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

Форматиране

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

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

• От Qt 4.7.1 използвайте именното пространство QtQuick, import QtQuick 1.0 – дава възможност за обратна съвместимост
• Името на .qml файла трябва да започва с главна буква
• Използвайте property alias и избягвайте дублирането свойства в компонента – използва се по-малко памет
• Използвайте всяко свойство на отделен ред – помага за четимостта на кода
• Ако групирате няколко свойства на един ред, групирайте ги по смисъл (например. x, y е логично и смислено, докато x, color – няма)
• Използвайте групирани от свойства, където срещнете логически групи от свойства (например font)
• Имената на свойствата трябва да започват с малка буква (с изключение на Прикрепените свойства [doc.qt.nokia.com])
• Използвайте квадратни скоби, дори когато присвоявате само една стойност на списък – така после по-лесно се разбира, че това е списък
• Дефинирайте обработката на сигнали с префикс “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())

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

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

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

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

Основните конвенции при писането на код можете да намерите тук [doc.qt.nokia.com]

Вижте също

• Qt_Quick_Donts_Bulgarian

Categories:

• Developing_with_Qt
  • Qt_Quick