From b2050c2e53da950c7ea9b3f8db64ab0ec48b2218 Mon Sep 17 00:00:00 2001 From: JunsuChoi Date: Fri, 24 Jul 2026 12:10:26 +0900 Subject: [PATCH] Remove Gemini review bot configuration --- .gemini/config.yaml | 17 ---------- .gemini/styleguide.md | 73 ------------------------------------------- 2 files changed, 90 deletions(-) delete mode 100644 .gemini/config.yaml delete mode 100644 .gemini/styleguide.md diff --git a/.gemini/config.yaml b/.gemini/config.yaml deleted file mode 100644 index a1697e69..00000000 --- a/.gemini/config.yaml +++ /dev/null @@ -1,17 +0,0 @@ -# Minimize verbosity. -have_fun: false -code_review: - # For now, use the default of MEDIUM for testing. Based on desired verbosity, - # we can change this to LOW or HIGH in the future. - comment_severity_threshold: MEDIUM - pull_request_opened: - help: false - summary: false - include_drafts: false -ignore_patterns: - # Avoid code reviews on rolls. - - DEPS - - "build/secondary/third_party/**" - - "flutter/fml/**" - - "flutter/third_party/**" - - "flutter/shell/platform/common/**" diff --git a/.gemini/styleguide.md b/.gemini/styleguide.md deleted file mode 100644 index 90023518..00000000 --- a/.gemini/styleguide.md +++ /dev/null @@ -1,73 +0,0 @@ -# Flutter Style Guide - -This style guide outlines the coding conventions for contributions to the -flutter-tizen/embedder repository. It is based on the more comprehensive official -[style guide for the Flutter repository](https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md). - -## Best Practices - -- Code should follow the guidance and principles described in - [the Flutter contribution guide](https://github.com/flutter/flutter/blob/main/CONTRIBUTING.md). -- For Flutter code, the - [Flutter styleguide](https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md) - should be followed as the first priority, and - should follow the [Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html). - -## Review Agent Guidelines - -- Only review changes to the `master` branch. Other changes have already been reviewed (and are being cherrypicked). - -## General Philosophy - -- **Optimize for readability**: Code is read more often than it is written. -- **Avoid duplicating state**: Keep only one source of truth. -- Write what you need and no more, but when you write it, do it right. -- **Error messages should be useful**: Every error message is an opportunity to make someone love our product. - -## Dart Formatting - -- All Dart code is formatted using `dart format`. This is enforced by CI. -- Constructors come first in a class definition, with the default constructor preceding named constructors. -- Other class members should be ordered logically (e.g., by lifecycle, or grouping related fields and methods). - -## Miscellaneous Languages - -- Python code is formatted using `yapf`, linted with `pylint`, and should follow the [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html). -- C++ code is formatted using `clang-format`, linted with `clang-tidy`. -- Shaders are formatted using `clang-format`. -- GN code is formatted using `gn format` and should follow the [GN Style Guide](https://gn.googlesource.com/gn/+/main/docs/style_guide.md). - -## Documentation - -- All public members should have documentation. -- **Answer your own questions**: If you have a question, find the answer, and then document it where you first looked. -- **Documentation should be useful**: Explain the *why* and the *how*. -- **Introduce terms**: Assume the reader does not know everything. Link to definitions. -- **Provide sample code**: Use `{@tool dartpad}` for runnable examples. - - Inline code samples are contained within `{@tool dartpad}` and `{@end-tool}`, and use the format of the following example to insert the code sample: - - `/// ** See code in examples/api/lib/widgets/sliver/sliver_list.0.dart **` - - Do not confuse this format with `/// See also:` sections of the documentation, which provide helpful breadcrumbs to developers. -- **Provide illustrations or screenshots** for widgets. -- Use `///` for public-quality documentation, even on private members. - -## Review Agent Guidelines - -When providing a summary, the review agent must adhere to the following principles: -- **Be Objective:** Focus on a neutral, descriptive summary of the changes. Avoid subjective value judgments - like "good," "bad," "positive," or "negative." The goal is to report what the code does, not to evaluate it. -- **Use Code as the Source of Truth:** Base all summaries on the code diff. Do not trust or rephrase the PR - description, which may be outdated or inaccurate. A summary must reflect the actual changes in the code. -- **Be Concise:** Generate summaries that are brief and to the point. Focus on the most significant changes, - and avoid unnecessary details or verbose explanations. This ensures the feedback is easy to scan and understand. - -## Further Reading - -For more detailed guidance, refer to the following documents: - -- [Style guide for the Flutter repository](https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md) -- [Effective Dart: Style](https://dart.dev/effective-dart/style) -- [Tree Hygiene](https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md) -- [The Flutter contribution guide](https://github.com/flutter/flutter/blob/main/CONTRIBUTING.md) -- [Writing effective tests guide](https://github.com/flutter/flutter/blob/main/docs/contributing/testing/Writing-Effective-Tests.md) -- [Running and writing tests guide](https://github.com/flutter/flutter/blob/main/docs/contributing/testing/Running-and-writing-tests.md) -- [Engine testing guide](https://github.com/flutter/flutter/blob/main/docs/engine/testing/Testing-the-engine.md)