|
1 | 1 | # Development Guidelines |
2 | 2 |
|
3 | 3 | ## Build Commands |
| 4 | + |
4 | 5 | - Build package: `./gradlew packageDistributionForCurrentOS` |
5 | 6 | - Run app: `./gradlew runDistributable` |
6 | 7 | - Run desktop app: `./gradlew :desktopApp:run` |
7 | 8 |
|
8 | 9 | ## Code Style |
| 10 | + |
9 | 11 | - **Naming**: Classes = PascalCase, Functions/Variables = camelCase |
10 | 12 | - **Architecture**: MVVM pattern with UI, State (Model), and Data layers |
11 | 13 | - **State Management**: Kotlin Flows (StateFlow for UI state) |
12 | 14 | - **Visibility Modifiers**: |
13 | | - - Use the most restrictive visibility modifier possible |
14 | | - - Prefer `internal` over `public` for implementation classes |
15 | | - - Use `private` for all properties and functions that don't need wider visibility |
16 | | - - Use `public` only for APIs that need to be accessed outside the module |
| 15 | + - Use the most restrictive visibility modifier possible |
| 16 | + - Prefer `internal` over `public` for implementation classes |
| 17 | + - Use `private` for all properties and functions that don't need wider visibility |
| 18 | + - Use `public` only for APIs that need to be accessed outside the module |
17 | 19 | - **DI**: Koin for dependency injection |
18 | | - - Use constructor injection whenever possible instead of property injection |
19 | | - - Constructor parameters make dependencies explicit and improve testability |
| 20 | + - Use constructor injection whenever possible instead of property injection |
| 21 | + - Constructor parameters make dependencies explicit and improve testability |
20 | 22 | - **Imports**: Grouped by purpose, explicit imports preferred over wildcards |
21 | 23 | - **Error Handling**: Repository pattern for data operations, proper error propagation through Flows |
22 | 24 | - **Expressive Kotlin Features**: |
23 | | - - Use `runCatching` instead of try-catch blocks |
24 | | - - Use `.use` extension for closeables |
25 | | - - Prefer `kotlin.io` extensions over Java IO streams |
26 | | - - Use scope functions (`let`, `apply`, `run`, `with`, `also`) appropriately |
27 | | - - Leverage extension functions for better readability |
28 | | - - Use property delegates (`by lazy`, `by Delegates`) where appropriate |
29 | | - - Use Elvis operator (`?:`) for fallback values |
| 25 | + - Use `runCatching` instead of try-catch blocks |
| 26 | + - Use `.use` extension for closeables |
| 27 | + - Prefer `kotlin.io` extensions over Java IO streams |
| 28 | + - Use scope functions (`let`, `apply`, `run`, `with`, `also`) appropriately |
| 29 | + - Leverage extension functions for better readability |
| 30 | + - Use property delegates (`by lazy`, `by Delegates`) where appropriate |
| 31 | + - Use Elvis operator (`?:`) for fallback values |
30 | 32 |
|
31 | 33 | ## Architecture Guidelines |
| 34 | + |
32 | 35 | - Network models (from APIs) should not be propagated to the presentation layer |
33 | 36 | - Always map network models to domain models in the repository layer |
34 | 37 | - Service layer handles API communication, Repository layer handles domain translation |
|
68 | 71 | ``` |
69 | 72 |
|
70 | 73 | ## Project Structure |
| 74 | + |
71 | 75 | - `feature/` - App features organized by domain (tracker, search, settings) |
72 | 76 | - `data/` - Repository interfaces, database models, network services |
73 | 77 | - `design/` - UI components, theme definitions |
74 | 78 | - `arch/` - Base architectural components |
75 | 79 | - `injection/` - Dependency injection modules |
76 | 80 |
|
77 | 81 | ## Testing |
| 82 | + |
78 | 83 | - Unit tests should follow the same structure as the feature they're testing |
79 | 84 | - Model tests should verify state transitions and event handling |
0 commit comments