I’m developing a Flutter project using Gemini for assistance.
I’ve started a GitHub repository, initially populated by Gemini, to document the development rules.
What specific guidelines, coding standards, and best practices should I establish and instruct Gemini to follow to ensure a high-quality and consistent Flutter application?
Give me your thought on rules that Gemini should use.
Seems to me that this would be a great question to ask Gemini in deep-research mode. (Either Gemini Advanced, or AI Studio.)
What are your experience comparing gemini to Claude or chatgpt for Flutter coding?
The rules that Gemini created for it self were very board.
Its opinion were as board as an entire community.
Do you have any rules you use?
# Gemini's Flutter App Development Guidelines
Hello there! These are the guidelines I'll use when I'm building Flutter applications for you. The goal is to create code that's clean, efficient, and easy for you to understand and build upon.
## Table of Contents App Development Guidelines
* [1. Project Setup & Structure](#1-project-setup--structure)
* [2. Coding Standards & Style](#2-coding-standards--style)
* [3. Widget Design & Composition](#3-widget-design--composition)
* [4. State Management](#4-state-management)
* [5. Asynchronous Operations & Error Handling](#5-asynchronous-operations--error-handling)
* [6. Navigation](#6-navigation)
* [7. Dependencies & Packages](#7-dependencies--packages)
* [8. Testing](#8-testing)
* [9. Performance](#9-performance)
* [10. Code Documentation & Comments](#10-code-documentation--comments)
* [11. Security Considerations](#11-security-considerations)
* [12. User Experience (UX) Focus](#12-user-experience-ux-focus)
* [13. Version Control Practices](#13-version-control-practices)
* [14. Continuous Improvement](#14-continuous-improvement)
---
## 1. Project Setup & Structure
The foundation of any good app is a clean and understandable project structure.
1. **Standard Initialization**: I'll always start new projects using the official `flutter create <project_name>` command to ensure a standard setup.
2. **Directory Organization**:
* I'll primarily use the `lib` directory for Dart code.
* Within `lib`, I may organize files by feature (e.g., `lib/features/authentication/`) or by layer (e.g., `lib/src/widgets/`, `lib/src/models/`, `lib/src/services/`), depending on the project's complexity. I'll aim for clarity and consistency.
* Assets (images, fonts, etc.) will be placed in a top-level `assets` directory and declared in `pubspec.yaml`.
* Tests will reside in the `test` directory.
3. **Naming Conventions**:
* File names will be in `snake_case.dart` (e.g., `user_profile_screen.dart`).
* Directories will also be in `snake_case`.
* Class names, enums, and typedefs will be in `UpperCamelCase`.
* Variables, methods, and parameters will be in `lowerCamelCase`.
* Constants will be in `lowerCamelCase` or `UPPER_SNAKE_CASE` if they are top-level or static consts.
## 2. Coding Standards & Style
Consistent code is readable code!
1. **Effective Dart**: I will adhere to the guidelines outlined in Effective Dart.
2. **Linting**: I'll use `flutter analyze` and strive to eliminate all warnings and errors. I'll assume a standard set of linting rules (e.g., from the `lints` or `flutter_lints` package).
3. **Formatting**: All Dart code will be formatted using `dart format` to ensure consistent styling.
4. **Readability**:
* I'll use meaningful names for variables, functions, and classes.
* I'll prefer `const` for variables and constructors where possible to improve performance and indicate immutability.
* I'll avoid overly long lines of code (typically aiming for around 80-100 characters).
* Functions and classes will be kept concise and focused on a single responsibility.
5. **Type Safety**: I will leverage Dart's strong type system by specifying types for variables, parameters, and return values. I'll use `dynamic` sparingly and only when necessary.
## 3. Widget Design & Composition
Flutter's UI is all about widgets, so I'll build them thoughtfully.
1. **Modularity**: I'll break down complex UIs into smaller, reusable widgets. Each widget will have a clear purpose.
2. **Stateless vs. Stateful**:
* I'll prefer `StatelessWidget` whenever a widget doesn't need to manage internal, mutable state.
* `StatefulWidget` will be used when a widget's appearance or behavior needs to change based on internal state or lifecycle events.
3. **`const` Constructors**: For widgets that can be constant, I will provide `const` constructors. This is crucial for performance optimizations.
4. **Separation of Concerns**: I'll strive to keep UI (widget) code separate from business logic.
5. **Responsive Design**: I'll consider how UIs should adapt to different screen sizes and orientations, using techniques like `MediaQuery`, `LayoutBuilder`, `FittedBox`, or responsive layout widgets.
6. **Build Method Purity**: Widget `build` methods should be pure and free of side effects. They should describe the UI based on the current state and props.
## 4. State Management
Managing state effectively is key to a robust Flutter app.
1. **Appropriate Solution**:
* For very simple, local state, I might use `setState`.
* For more complex scenarios, I'll choose a well-established state management solution (e.g., Provider, Riverpod, BLoC/Cubit, GetX). The choice will depend on the project's scale and requirements, or your preference if specified.
2. **Clear State Flow**: The flow of data and state changes will be designed to be predictable and easy to trace.
3. **Scoped State**: I'll aim to keep state as localized as possible, providing it only to the widgets that need it.
4. **Immutability**: When using more advanced state management, I'll often favor immutable state objects to ensure predictability and simplify debugging.
## 5. Asynchronous Operations & Error Handling
Handling operations that take time, and dealing with potential errors, is crucial.
1. **`async/await`**: I'll use `async` and `await` for clear and readable asynchronous code.
2. **Futures and Streams**: I'll use `FutureBuilder` and `StreamBuilder` appropriately to reactively build UI based on the state of asynchronous operations.
3. **Loading States**: I'll ensure UIs provide feedback during asynchronous operations (e.g., loading indicators).
4. **Error Handling**:
* I'll use `try-catch` blocks to handle potential exceptions in asynchronous code.
* I'll aim to display user-friendly error messages rather than crashing the app or showing raw error details.
* I'll check if a widget `mounted` before calling `setState` or accessing `context` in asynchronous callbacks to prevent errors.
## 6. Navigation
Getting around the app should be intuitive.
1. **Named Routes**: I'll prefer using named routes (`Navigator.pushNamed`) for navigation, as it makes routing logic cleaner and more manageable, especially for larger apps.
* Example: `Navigator.pushNamed(context, '/profile');`
2. **Route Arguments**: I'll pass arguments to routes in a type-safe manner, often by defining argument classes.
3. **Routing Packages**: For applications with complex navigation requirements (deep linking, nested routing), I might suggest or use a dedicated routing package like `go_router`.
## 7. Dependencies & Packages
I'll leverage the rich Flutter ecosystem responsibly.
1. **Judicious Use**: I'll only add packages from `pub.dev` when they provide significant value and are well-maintained.
2. **Version Pinning**: I'll specify dependency versions in `pubspec.yaml` carefully, often using caret syntax (e.g., `^1.2.3`) to allow compatible updates while ensuring stability.
3. **Up-to-Date**: I'll try to use recent, stable versions of packages.
4. **Cleanup**: I'll remind you or attempt to remove unused dependencies to keep the project lean.
## 8. Testing
To ensure quality and maintainability, testing is essential.
1. **Unit Tests**:
* **I will always aim to generate unit tests for new functions and methods, especially those containing business logic.**
* These tests will verify the correctness of individual functions, methods, or classes in isolation.
* I'll use the `test` package.
2. **Widget Tests**:
* I'll write widget tests to verify that widgets render correctly and respond to user interactions as expected.
* I'll use the `flutter_test` package.
3. **Integration Tests**: For more complex flows, I might suggest or provide integration tests.
4. **Test Coverage**: I'll aim for reasonable test coverage, focusing on critical paths and complex logic.
5. **Mocking**: I'll use mocking (e.g., with the `mockito` package) to isolate units under test from their dependencies.
## 9. Performance
A smooth and responsive app is a joy to use.
1. **Widget Rebuilds**: I'll be mindful of minimizing unnecessary widget rebuilds. This includes:
* Using `const` widgets wherever possible.
* Breaking down large widgets.
* Properly using state management to update only necessary parts of the UI.
2. **`ListView.builder`**: For long lists, I'll always use `ListView.builder` (or similar constructors like `GridView.builder`) for performance.
3. **Lazy Loading**: I'll implement lazy loading for data and resources where appropriate.
4. **DevTools**: I'll encourage the use of Flutter DevTools for profiling and identifying performance bottlenecks.
5. **Avoid Expensive Operations in Build**: I'll avoid performing expensive computations or I/O operations directly within `build` methods.
## 10. Code Documentation & Comments
Code should be understandable not just by machines, but by humans too!
1. **Dartdocs**: I'll write Dartdoc comments (`///`) for all public classes, methods, functions, and important properties. This helps in generating documentation and improves code understanding.
* Example:
```dart
/// Fetches user data from the server.
///
/// Throws a [NetworkException] if the request fails.
Future<User> fetchUserData(String userId) async {
// ... implementation ...
}
```
2. **Inline Comments**: I'll use inline comments (`//`) to explain complex, non-obvious, or tricky parts of the code.
3. **Clarity over Quantity**: Comments will be used to clarify *why* something is done, not just *what* is done (if the code itself is clear).
4. **Keep Updated**: I'll try to ensure comments and documentation are kept in sync with code changes.
## 11. Security Considerations
Building secure apps is a top priority.
1. **Sensitive Data**: I will avoid hardcoding sensitive information (API keys, secrets) directly in the client-side code. I'll recommend using environment variables or secure storage solutions.
2. **Network Communication**: I'll default to using HTTPS for all network requests.
3. **Input Validation**: I'll implement input validation on both client-side and server-side (though I primarily generate client-side code).
4. **Dependency Security**: I'll be mindful of potential vulnerabilities in third-party packages.
5. **Local Storage**: When using local storage (e.g., `shared_preferences`, `flutter_secure_storage`), I'll consider the sensitivity of the data being stored.
## 12. User Experience (UX) Focus
While I generate code, I'll keep the end-user experience in mind.
1. **Feedback**: I'll ensure the app provides appropriate feedback for user actions (e.g., taps, loading states, success/error messages).
2. **Accessibility (A11y)**: I'll try to use widgets and practices that support accessibility, such as providing semantic labels and ensuring sufficient contrast (though visual design is often iterative).
3. **Platform Conventions**: I'll aim to follow common UI/UX patterns for iOS and Android where appropriate, or create a consistent custom design.
4. **Intuitive Interfaces**: I'll strive to generate UIs that are intuitive and easy to navigate.
## 13. Version Control Practices
Good version control hygiene is important for collaboration and project history. While I don't directly commit code, I'll generate it in a way that's conducive to good VCS practices.
1. **`.gitignore`**: I'll assume a standard Flutter `.gitignore` file is in use to exclude unnecessary files from version control.
2. **Logical Changes**: When I make changes or add features, I'll try to do so in logical, self-contained chunks that would correspond to good commit practices.
## 14. Continuous Improvement
The Flutter ecosystem is always evolving, and so am I!
1. **Stay Updated**: I'll be continuously updated with the latest Flutter features, Dart language enhancements, and community best practices.
2. **Adaptability**: I'll be open to adapting these guidelines based on new information, specific project requirements, or your feedback.
I am using Gemini at the moment.
Will be nice to see what other options are available as well and how to optimize them to accelerate your dev work.
We will be discussing rules during our Flutter Community AI Circle (FCAIC) livestream Monday 12-May at 16:00 UTC (9:00 PDT aka “Google time”).
You can find the FCAIC YouTube playlist, with upcoming shows included, here.
One big problem seems to be that if your project is beyond a certain size the models can’t fully Analyse it and keep that in memory.
I had constantly the problem that the Agent forgot several files to update them.
On the other side it removed a full content of a constructor without asking. 
I ran into the same issue.
That’s why I built llmifier. It extracts your Dart/Flutter project into a single, LLM-optimized file (llms.txt), organized for better comprehension and reliability.
Depending on your project size and use case, you can choose:
-m full: full context for reviews or architecture questions-m api: only public API + docs for focused generation or onboardingMy workflow is simple: dart pub global activate llmifier
llmifier to generate llms.txtllms.txt to an LLM with a large context windowAnother example: When I want to explore a package the LLM doesn’t fully know yet (e.g. riverpod 3.0.0-dev.15):
dart pub unpack riverpod:3.0.0-dev.15
cd riverpod-3.0.0-dev.15
llmifier -m api -o llms-riverpod-api.txt --exclude example --exclude test
This produces a ~60,000 token summary of the public API — perfect for deep prompting or migration planning.
It’s made my LLM workflows far more consistent.
That sounds really interesting. How do I feed the generated file to the agent in Cursor?
I’ve only used llms.txt in web-based LLM interfaces so far, but the inspiration for this workflow actually came from DaisyUI — they describe a neat way to use context files with Cursor here:
https://daisyui.com/docs/editor/cursor/
Would love to hear if it works well for you in Cursor too! Always curious how others integrate these tools into their workflow.
How does this work, do you copy the content of that txt into the prompt of for example gemini’s?
Yes! Here’s how I typically use it:
llms.txt file as Project knowledge. That way, Claude has persistent context and can reference the project across multiple prompts.llms.txt directly into the first prompt — without a question. Just a simple instruction like:Once the LLM has that context, I follow up with more specific questions or tasks.
Supported by Invoice Ninja and Event Schedule
It's All Widgets! • Flutter Pro • FlutterX • Flutter Streams • Flutter Podcast
Using contents of this forum for the purposes of training proprietary AI models is forbidden. Only if your AI model is free & open source, go ahead and scrape. Flutter and the related logo are trademarks of Google LLC. We are not endorsed by or affiliated with Google LLC.