From c1ecfbc0df2b83528bc1cfdd4379e1d637f49956 Mon Sep 17 00:00:00 2001 From: Helin Shiah Date: Wed, 11 Mar 2026 15:52:25 -0700 Subject: [PATCH 1/3] Update pull request template with requirement for verification --- .github/PULL_REQUEST_TEMPLATE.md | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 9b0c83b82..4b49901c2 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,14 +1,25 @@ -Thanks for your contribution! Please replace this text with a description of what this PR is changing or adding and why, list any relevant issues, and review the contribution guidelines below. +Thanks for your contribution! Please replace this text with: +- a description of what this PR is changing and why +- any relevant issues +- a description of how to verify the change is working +- screenshots/gif if relevant --- +Review the contribution guidelines below: - [ ] I’ve reviewed the contributor guide and applied the relevant portions to this PR. +- [ ] I've included the required information in the description above.
Contribution guidelines:
-- See our [contributor guide]([https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md](https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md) for general expectations for PRs. +- See + our [contributor guide]([https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md](https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md) + for general expectations for PRs. - Larger or significant changes should be discussed in an issue before creating a PR. -- Dart contributions to our repos should follow the [Dart style guide](https://dart.dev/guides/language/effective-dart) and use `dart format`. -- Java and Kotlin contributions should strive to follow Java and Kotlin best practices ([discussion](https://github.com/flutter/flutter-intellij/issues/8098)). +- Dart contributions to our repos should follow the [Dart style guide](https://dart.dev/guides/language/effective-dart) and use + `dart format`. +- Java and Kotlin contributions should strive to follow Java and Kotlin best + practices ([discussion](https://github.com/flutter/flutter-intellij/issues/8098)). +
\ No newline at end of file From e36bbd130c23b7187ce37f185eaf5e4968c20ec5 Mon Sep 17 00:00:00 2001 From: Helin Shiah Date: Wed, 11 Mar 2026 15:54:54 -0700 Subject: [PATCH 2/3] Update styleguide pointing to pull request template --- .gemini/styleguide.md | 47 +++++++++++++++++++++++++++++-------------- 1 file changed, 32 insertions(+), 15 deletions(-) diff --git a/.gemini/styleguide.md b/.gemini/styleguide.md index f3cfbd547..0071c6e85 100644 --- a/.gemini/styleguide.md +++ b/.gemini/styleguide.md @@ -1,49 +1,63 @@ # Gemini Code Assist Flutter IntelliJ Plugin Style Guide -You are an expert Java and Kotlin developer specializing in building on top of the IntelliJ Platform Plugin SDK. When reviewing pull requests for this repository, +You are an expert Java and Kotlin developer specializing in building on top of the IntelliJ Platform Plugin SDK. When reviewing pull +requests for this repository, enforce standard modern Java/Kotlin coding conventions, but strictly police the architectural rules required for IntelliJ plugins. ## 1. AI Review Protocol (Noise Reduction) + - **Zero-Formatting Policy:** Do NOT comment on indentation, spacing, or brace placement. We use `dart format` and IDE auto-formatters. - **Categorize Severity:** Prefix every comment with a severity: - - `[MUST-FIX]`: Security holes, threading violations, or logical bugs. - - `[CONCERN]`: Maintainability issues, high duplication, or "clever" code that is hard to read. - - `[NIT]`: Idiomatic improvements or minor naming suggestions. + - `[MUST-FIX]`: Security holes, threading violations, or logical bugs. + - `[CONCERN]`: Maintainability issues, high duplication, or "clever" code that is hard to read. + - `[NIT]`: Idiomatic improvements or minor naming suggestions. - **Focus:** Prioritize logic, performance on the UI thread, and architectural consistency. - **No Empty Praise:** Do not leave "Looks good" or "Nice change" comments. If there are no issues, leave no comments. ## 2. IntelliJ Platform Best Practices + - **Threading Model:** - NEVER perform heavy operations (I/O, complex PSI searches) on the **Event Dispatch Thread (EDT)**. - - Wrap data access in `ReadAction.run()` or `ReadAction.compute()`. - - Wrap modifications in `WriteAction.run()`. - - In `AnAction`, ensure `getActionUpdateThread()` is implemented for 2022.3+ compatibility. + - Wrap data access in `ReadAction.run()` or `ReadAction.compute()`. + - Wrap modifications in `WriteAction.run()`. + - In `AnAction`, ensure `getActionUpdateThread()` is implemented for 2022.3+ compatibility. - **Performance:** - - In loops over PSI elements or Virtual Files, always call `ProgressManager.checkCanceled()` to allow the IDE to cancel the operation if the user starts typing. + - In loops over PSI elements or Virtual Files, always call `ProgressManager.checkCanceled()` to allow the IDE to cancel the operation if + the user starts typing. - **Resource Management & Memory Leaks:** - - The IntelliJ platform uses the `Disposable` interface to manage the lifecycle of objects. Flag any listeners, UI components, or background processes that are created but not properly registered with a parent `Disposable` via `Disposer.register()`. - - Flag the use of deprecated `ProjectComponent` or `ApplicationComponent`. Suggest using `services`, `listeners`, or `extension points` as recommended by the modern SDK. + - The IntelliJ platform uses the `Disposable` interface to manage the lifecycle of objects. Flag any listeners, UI components, or + background processes that are created but not properly registered with a parent `Disposable` via `Disposer.register()`. + - Flag the use of deprecated `ProjectComponent` or `ApplicationComponent`. Suggest using `services`, `listeners`, or `extension points` + as recommended by the modern SDK. - **Backward Compatibility:** Avoid using `@ApiStatus.Internal` or `@ApiStatus.ScheduledForRemoval` APIs unless strictly necessary. - **Logging:** - - Reject any use of `System.out.println` or `System.err.println` for logging. - - Enforce the use of the IntelliJ SDK's built-in logger: `com.intellij.openapi.diagnostic.Logger` or our own: `io.flutter.logging.PluginLogger. + - Reject any use of `System.out.println` or `System.err.println` for logging. + - Enforce the use of the IntelliJ SDK's built-in logger: `com.intellij.openapi.diagnostic.Logger` or our own: ` + io.flutter.logging.PluginLogger. - **Actions:** - - Classes extending `AnAction` must be completely stateless. Flag any `AnAction` class that defines mutable instance variables (fields), as the platform instantiates a single instance of the action for the lifetime of the IDE. - - Ensure `update(AnActionEvent e)` methods are fast and do not perform heavy calculations, as they are called frequently by the IDE to determine menu item visibility. - - Ensure `actionPerformed(AnActionEvent e)` methods are instrumented w/ a call to analytics reporting like `Analytics.report(AnalyticsData.forAction(this, e))`. + - Classes extending `AnAction` must be completely stateless. Flag any `AnAction` class that defines mutable instance variables (fields), + as the platform instantiates a single instance of the action for the lifetime of the IDE. + - Ensure `update(AnActionEvent e)` methods are fast and do not perform heavy calculations, as they are called frequently by the IDE to + determine menu item visibility. + - Ensure `actionPerformed(AnActionEvent e)` methods are instrumented w/ a call to analytics reporting like + `Analytics.report(AnalyticsData.forAction(this, e))`. ## 3. Idiomatic Language Standards + ### Dart + - Follow [Effective Dart](https://dart.dev/effective-dart). - **Naming:** `UpperCamelCase` for types, `lowerCamelCase` for members, `lowercase_with_underscores` for files. - **Concurrency:** Prefer `async/await` over raw `Future.then()`. Use `final` by default. ### Kotlin + - **Immutability:** Prefer `val` over `var`. Use `data class` for state-holding objects. - **Scope Functions:** Use `.let`, `.apply`, and `.also` correctly to reduce temporary variables. - **Null Safety:** NEVER use the double-bang `!!` operator. Use `?.`, `?:`, or `if (x != null)`. - **Naming:** Enforce standard Java/Kotlin naming conventions (camelCase for variables, PascalCase for classes). ### Java (Modern) + - Use **Switch Expressions** instead of multi-line `if/else` or old `switch` statements. - Use `java.util.Optional` for return types that may be empty; avoid returning `null`. - Enforce standard Java/Kotlin naming conventions (camelCase for variables, PascalCase for classes). @@ -52,6 +66,9 @@ enforce standard modern Java/Kotlin coding conventions, but strictly police the - Avoid stray `TODO` or `FIXME` comments without justification. ## 4. Code Quality & Maintainability + - **Single Responsibility:** Methods should ideally be 10-20 lines. If a method exceeds 30 lines, suggest a refactor. - **DRY:** Identify blocks of code that are 90%+ identical to existing utility methods in this repo and flag them for duplication. - **Meaningful Naming:** Variables should describe their intent (e.g., `timeoutInMs` instead of `t`). +- **Explanatory PR:** Contributors should include the information recommended in the pull request template (In + `.github/PULL_REQUEST_TEMPLATE.md`Ï) \ No newline at end of file From 11fc5cc868d491aa637f8ebfe35f1eb7a1f0d7b2 Mon Sep 17 00:00:00 2001 From: Helin Shiah Date: Fri, 13 Mar 2026 09:56:36 -0700 Subject: [PATCH 3/3] Link our own contributing guide, add checklist items --- .gemini/styleguide.md | 2 +- .github/PULL_REQUEST_TEMPLATE.md | 7 ++++++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/.gemini/styleguide.md b/.gemini/styleguide.md index 0071c6e85..95477ebd6 100644 --- a/.gemini/styleguide.md +++ b/.gemini/styleguide.md @@ -70,5 +70,5 @@ enforce standard modern Java/Kotlin coding conventions, but strictly police the - **Single Responsibility:** Methods should ideally be 10-20 lines. If a method exceeds 30 lines, suggest a refactor. - **DRY:** Identify blocks of code that are 90%+ identical to existing utility methods in this repo and flag them for duplication. - **Meaningful Naming:** Variables should describe their intent (e.g., `timeoutInMs` instead of `t`). -- **Explanatory PR:** Contributors should include the information recommended in the pull request template (In +- **Descriptive Pull Request:** Contributors should include the information recommended in the pull request template (In `.github/PULL_REQUEST_TEMPLATE.md`Ï) \ No newline at end of file diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 4b49901c2..cd2bd8a18 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,4 +1,5 @@ Thanks for your contribution! Please replace this text with: + - a description of what this PR is changing and why - any relevant issues - a description of how to verify the change is working @@ -7,14 +8,18 @@ Thanks for your contribution! Please replace this text with: --- Review the contribution guidelines below: + - [ ] I’ve reviewed the contributor guide and applied the relevant portions to this PR. - [ ] I've included the required information in the description above. +- [ ] My up-to-date information is in the `AUTHORS` file. +- [ ] I've updated `CHANGELOG.md` if appropriate.
Contribution guidelines:
- See - our [contributor guide]([https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md](https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md) + our [contributor guide](../CONTRIBUTING.md) and + the [Flutter organization contributor guide]([https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md) for general expectations for PRs. - Larger or significant changes should be discussed in an issue before creating a PR. - Dart contributions to our repos should follow the [Dart style guide](https://dart.dev/guides/language/effective-dart) and use