Rationale explains why a requested code change is warranted. It gives the author context, justification, and evidence instead of merely describing what the code does. section 6.1.3
Compose a change request with the Triple-R pattern:
- Request: state the transformation with a concise, actionable verb. section 6.1.3
- Rationale: explain why the request is warranted, adding references or links when useful. section 6.1.3
- Result: define a measurable end state, such as a metric, screenshot, or expected code shape. section 6.1.3
Moving a method
Request: move AuthenticateUser() into AuthenticationUtilities. Rationale: related methods already belong there, the method is called repeatedly, and the team agreement recommends that placement. section 6.1.3
needs change: Can we update this endpoint to use version 3 (v3)? The call to our getCoordinates() method currently references version 2 (v2), a soon- to-be-deprecated (link) version, which will cause functionality to break. Also, our other endpoints are already using v3; updating this will keep our code consistent.
Compare consistency and deprecation evidence in a concise endpoint-change rationale. section 6.1.3
