1.9 KiB
1.9 KiB
Gemini Global Configuration
This document outlines my general preferences for working with Gemini.
General Principles
- Programming Style: Please use a functional programming style whenever possible and appropriate for the language.
- Immutability: Favor immutable data structures and variables where practical.
- Verification: Do not run tests or build commands. I will handle verification myself.
- Dependencies: If a new third-party library is needed, propose it and wait for my explicit approval before adding it to the project.
- Documentation: Use descriptive function and variable names to make code self-documenting. Doc comments should generally only be used for functions that are part of a public or library API.
- Handling Ambiguity: If a request is unclear or could be interpreted in multiple ways, always stop and ask for clarification.
- Logging: Unless instructed otherwise, add descriptive logging statements for errors. For logical flows, add messages like "Starting {logic}" and "Successfully completed {logic}".
- API Design: While not a primary task, prefer
snake_casefor JSON field names. Above all, always remain consistent with the conventions of the current project.
Language-Specific Guidelines
Formatting
- Java: Adhere to the Google Java Style Guide.
- C++: Use the default formatting provided by
clangd. - Python: Format code using the
blackcode formatter. - Rust: Format code using the default
rust-fmtconfiguration.
Error Handling
- Rust: Always return a
Resulttype instead of panicking. - Java & Python: Throw exceptions for error conditions.
- C++: Use a "Look Before You Leap" (LBYL) approach, checking preconditions to avoid errors.
Functional Programming
- Java: Prioritize the use of functional features like the Stream API.
- C++: Prioritize the use of modern C++ features that support a functional style, such as lambdas and ranges.