Style & Conventions rules

Extract numeric literals with meaning into named constants or readonly fields.

Use the standard logging module (or your app's logger) instead of print() in committed code.

When returning (T, error), return the zero value for T (or nil for pointers/slices/maps) whenever error != nil.

Components with no content should be self-closing in Single-File Components, string templates, and JSX - but never in in-DOM templates.

Detect unnecessary nesting where an if statement is the only statement inside an else block. Recommend using else-if instead for improved readability.

Filenames of Single-File Components should either be always PascalCase or always kebab-case.

The top-level tags (`<script>`, `<template>`, `<style>`) in Single-File Components (.vue files) should be ordered consistently across the project. A common convention is `<script>`, then `<template>`, then `<style>`.

Use lowerCamelCase for parameters; prefer full, descriptive names over abbreviations.

When using iota to create enums (constant sets), start from 1 and use 0 as a 'zero value' meaning undefined or default. This way, an uninitialized variable of that enum type will not accidentally hold a valid value.

Child components that are tightly coupled with their parent should include the parent component name as a prefix.

Ensure that all overridden methods explicitly use the `@Override` annotation.

Use `///` instead of regular comments to properly document Dart classes, methods, and properties for automatic documentation generation.

Check if class and module titles use `CamelCase`. If not, suggest renaming them for consistency.

Replace `static final` with `const` where applicable to enable compile-time evaluation and optimize performance.

Identify occurrences where `== None` or `!= None` is used. Using `is None` and `is not None` is more reliable because it checks identity instead of equality, preventing potential issues with overloaded `__eq__` methods.

Check if `var` is used only when the variable type is clear and enhances readability. Avoid using `var` when the type is not obvious.

Detect relative imports (e.g., `from .module import x`). Relative imports can break if the project structure changes. Recommend using absolute imports (`from package.module import x`) for better clarity and maintainability.

Alias imports when names overlap with locals or other modules; keep clear, unique identifiers.

Use the time package's types for handling time. For example, represent instants as `time.Time` and durations or time intervals as `time.Duration` instead of raw numeric types (int, int64).

Ensure that list, set, or dictionary comprehensions are not overly complex. If a comprehension includes multiple conditions or nested loops, recommend refactoring to a regular loop for better readability.

Error strings should start with a lowercase letter and not end with punctuation. They should state what went wrong in a concise, factual manner (for example, "file not found", not "File not found!").

Choose names that reflect intent; avoid abbreviations except widely accepted ones.

Prefer intent-revealing names over cryptic abbreviations.

Ensure that destructuring is used in function parameters where applicable. This improves readability by clearly showing accessed properties and default values.