Add kiro steering docs #6280
Add kiro steering docs #6280
Conversation
|
| return fallbackData(); | ||
| }, executor); | ||
| ``` | ||
| - **Use appropriate completion methods**: |
There was a problem hiding this comment.
what about whenComplete? We use it a lot
| - Include comprehensive Javadoc for public APIs | ||
| - Keep methods short and focused on a single responsibility | ||
| - Limit the number of method parameters (ideally 3 or fewer) | ||
| - Use appropriate access modifiers (private, protected, public) |
There was a problem hiding this comment.
will Kiro know what is "appropriate" or should we elaborate?
| - If the class does not implement `Supplier`: `{Noun}Provider` (e.g. `AwsCredentialsProvider`) | ||
| - If the "get" method has parameters: `{Noun}Factory` (e.g. `AwsJsonProtocolFactory`) | ||
|
|
||
| #### Service-specific classes |
There was a problem hiding this comment.
Does this section seems a bit restrictive? We don't want any other options?
| ``` | ||
| - `equals()`: Compare all fields for equality, including proper null handling | ||
| - `hashCode()`: Include all fields in the hash code calculation | ||
| - Consider using IDE-generated implementations |
There was a problem hiding this comment.
SDK ToString utils for toString()?
| - `Optional` **SHOULD** be used when it is not obvious to a caller whether a result will be null | ||
| - `Optional` **MUST NOT** be used for "getters" in generated service model classes | ||
| - For member variables: `Optional` **SHOULD NOT** be used | ||
| - For method parameters: `Optional` **MUST NOT** be used |
There was a problem hiding this comment.
Should we provide guidance to use @nullable instead or just not doing it?
| - All public POJO classes **MUST** implement `toString()`, `equals()`, and `hashCode()` methods | ||
| - When adding new fields to existing POJO classes, these methods **MUST** be updated to include the new fields | ||
| - Implementation guidelines: | ||
| - `toString()`: Include class name and all fields with their values |
There was a problem hiding this comment.
Possible additional guideline - do not include fields that could be considered sensitive such as credentials
| ``` | ||
| - `equals()`: Compare all fields for equality, including proper null handling | ||
| - `hashCode()`: Include all fields in the hash code calculation | ||
| - Consider using IDE-generated implementations |
There was a problem hiding this comment.
Is this guidance useful for kiro? I think we often use the intelliJ auto-generated implementations, but not sure that will apply well here. I think the guidance maybe should be either: use java.util.Objects helpers or write explicit code.
Motivation and Context
Add kiro steering docs. I added existing guidelines from docs folder and internal docs. I also added additional guidelines that came to my mind.