flutter-format

# Flutter Format

Expert knowledge about Flutter/Dart code formatting and analysis tools.

## Core Tools

### flutter analyze
**Purpose**: Static analysis to find errors, warnings, and lint suggestions

**What it checks:**
- Syntax errors
- Type errors
- Unused imports and variables
- Lint rules from analysis_options.yaml
- Potential bugs and anti-patterns

**When to use:**
- Before applying fixes (to identify issues)
- After formatting (to verify no new issues)
- As pre-commit validation

**Output interpretation:**
- **Errors**: Must fix (compilation failures)
- **Warnings**: Should fix (potential bugs)
- **Info**: Optional improvements (style suggestions)

### dart fix --apply
**Purpose**: Automatically fix lint issues and apply Dart language updates

**What it fixes:**
- Deprecated API usage
- Lint violations with automated fixes
- Code modernization (e.g., null safety migration patterns)

**When to use:**
- After flutter analyze identifies fixable issues
- Before formatting (fixes may affect structure)
- When migrating Dart versions

**Safety considerations:**
- **Safe**: Lint fixes, deprecated API updates
- **Review needed**: Major refactorings, null safety changes
- **Skip if**: Syntax errors present, uncommitted important changes

**Always show changes to user** with git diff before proceeding.

### dart format
**Purpose**: Consistent code formatting following Dart style guide

**What it formats:**
- Indentation (2 spaces)
- Line length (default 80 characters)
- Bracket placement
- Whitespace and newlines

**What it doesn't change:**
- Code logic
- Import order (use IDE or separate tool)
- Comments content

**When to use:**
- After code changes
- After dart fix --apply
- Before commits

**Options:**
- . - Format entire project
- lib test - Format specific directories
- --line-length=120 - Custom line length (if needed)

## Best Practices

### Recommended Workflow

**Standard sequence:**
```
flutter analyze → dart fix --apply → dart format → flutter analyze
``