# LVGL Pro Best Practices (/xml/best_practices)



These guidelines help keep projects organized, maintainable, and easier to scale when working with the LVGL Pro Editor.

1\. Project Naming [#1-project-naming]

Avoid project names that may conflict with libraries or frameworks.

**Do NOT use:**

* `lvgl`

**Recommended:**

* Use a unique project name specific to your project.

This prevents naming conflicts and keeps the build system clean.

2\. Asset Organization [#2-asset-organization]

Use clear and consistent prefixes for generated assets.

**Images**

* `icon_`
* `image_`

**Fonts**

Use structured naming to handle different sizes and styles:

* `font_<name>_<size>`
* `font_<name>_<size>_<format>`

**Examples:**

* `font_roboto_14_regular`
* `font_roboto_16_bold`

This is especially important when managing multiple font sizes and formats such as bold, italic, or medium.

3\. Raw Resource Separation [#3-raw-resource-separation]

Keep raw resources separate from generated resources.

**Recommended structure:**

```c title=" " lineNumbers=1
images/
images/raw/
```

```c title=" " lineNumbers=1
images/raw/icon_home.png
images/icon_home.c
```

* `icon_home_20dp.png`
* `icon_home_40dp.png`

**Benefits:**

* Generated files remain easy to locate
* Raw assets are not mixed with generated files
* Project structure remains clean and predictable

4\. Subject Naming [#4-subject-naming]

Use a consistent prefix for subjects.

* `subject_settings`
* `subject_home`

This improves readability and ensures naming consistency across the project.

5\. Style Naming [#5-style-naming]

Always prefix styles.

**Base styles:**

* `style_button`
* `style_container`
* `style_text`

**Theme variants:**

If multiple themes are used (e.g., dark and light), include a theme prefix:

* `style_dark_button`
* `style_light_button`

This approach simplifies theme management and scaling.

6\. Screens, Components, and Widgets [#6-screens-components-and-widgets]

Create screens, components, and widgets using their respective folders.

**Recommended approach:**

Use:

* *Add New → Component*
* *Add New → Widget*
* *Add New → Screen*

This automatically organizes them into subfolders, improving navigation and maintainability.

7\. Widget Naming [#7-widget-naming]

Use a prefix for widgets:

* `wd_menu`
* `wd_statusbar`
* `wd_clock`

This makes widgets easy to identify and avoids naming conflicts.

8\. Do Not Edit Generated Files [#8-do-not-edit-generated-files]

Files generated by the editor are overwritten during regeneration.

**Do not modify them directly.**

**Instead:**

* Modify the source XML
* Use styles
* Use components or widgets

Direct edits to generated files will be lost.

9\. Avoid Inline Styles in XML [#9-avoid-inline-styles-in-xml]

Minimize the use of inline style attributes.

**Avoid:**

```xml title="xml" lineNumbers=1
<lv_obj style_bg_color="0x000000" style_bg_opa="255" />
```

**Recommended:**

```xml title="xml" lineNumbers=1
<styles>
   <style name="style_obj" bg_color="0x000000" bg_opa="255" />
</styles>

<lv_obj>
   <style name="style_obj" />
</lv_obj>
```

**Benefits:**

* Styles are reusable
* XML remains clean and readable
* Easier maintenance and updates

10\. Avoid API Properties in Components/Widgets [#10-avoid-api-properties-in-componentswidgets]

Avoid defining API properties that may conflict with editor-specific behavior.

**Avoid:**

```xml title="xml" lineNumbers=1
<prop name="name" type="text" />
```

Also avoid unnecessary API overrides:

```xml title="xml" lineNumbers=1
<api>
   <prop name="width" type="int" />
</api>

<view width="$width" />
```

**Recommended:**

Use the `help` property to document API usage:

```xml title="xml" lineNumbers=1
<api name="text" type="string" help="Sets the label text of the component" />
```

11\. Avoid Overriding Default Flags or State [#11-avoid-overriding-default-flags-or-state]

Avoid overriding default states or flags on the root object unless necessary.

**Avoid:**

```xml title="xml" lineNumbers=1
<component>
   <view checked="true" />
</component>
```

**Recommended:**

Set such properties when the component is used within a screen.

This ensures components remain flexible and reusable.

12\. Component Sizing Best Practices [#12-component-sizing-best-practices]

Avoid combining fixed component sizes with fixed child sizes.

**Not recommended:**

```xml title="xml" lineNumbers=1
<view width="content">
   <lv_dropdown width="420" />
</view>
```

This prevents proper resizing when the component is reused.

**Recommended:**

```xml title="xml" lineNumbers=1
<view width="420">
   <lv_dropdown width="100%" />
</view>
```

**Benefits:**

* Child elements resize automatically
* Components can be reused at different sizes
* Layout behavior remains predictable