What's needed?
The gRPC methods specified in the provided documentation exhibit clarity in terms of which entity the method verb pertains to. For instance, methods like GetMicrogridMetadata, ListComponents, ListConnections, and StreamComponentData explicitly convey the application of their respective verbs to specific entities. For example, ListComponents promptly indicates that the verb 'List' operates on 'Components', ensuring precise comprehension.
However, this clarity is not consistently present across all methods. Some methods such as Start, HotStandby, ColdStandby, Stop, and ErrorAck lack this specification. As these actions pertain to individual components, it's advisable to incorporate the term Component into their names to ensure clarity.
Furthermore, while methods like SetPowerActive, SetPowerReactive, AddExclusionBounds, and AddInclusionBounds accurately denote the action they perform, they fall short in specifying the entity upon which the action is executed. It's recommended to include the term Component in the names of these methods to enhance precision in conveying the entity of the action.
By adhering to this naming convention, the gRPC methods will consistently provide clear insight into the entities and actions they concern, contributing to a more comprehensible and user-friendly API documentation.
Proposed solution
The following method names require revision:
AddExclusionBounds should be renamed to AddComponentExclusionBounds.AddInclusionBounds should be renamed to AddComponentInclusionBounds.SetPowerActive should be renamed to SetComponentPowerActive.SetPowerReactive should be renamed to SetComponentPowerReactive.Start should be renamed to StartComponent.HotStandby should be renamed to HotStandbyComponent.ColdStandby should be renamed to ColdStandbyComponent.Stop should be renamed to StopComponent.
By incorporating the term "Component" into these method names, the actions will be distinctly associated with the relevant entity, leading to greater clarity and coherence within the API documentation.
Use cases
No response
Alternatives and workarounds
No response
Additional context
No response
What's needed?
The gRPC methods specified in the provided documentation exhibit clarity in terms of which entity the method verb pertains to. For instance, methods like
GetMicrogridMetadata,ListComponents,ListConnections, andStreamComponentDataexplicitly convey the application of their respective verbs to specific entities. For example,ListComponentspromptly indicates that the verb 'List' operates on 'Components', ensuring precise comprehension.However, this clarity is not consistently present across all methods. Some methods such as
Start,HotStandby,ColdStandby,Stop, andErrorAcklack this specification. As these actions pertain to individual components, it's advisable to incorporate the termComponentinto their names to ensure clarity.Furthermore, while methods like
SetPowerActive,SetPowerReactive,AddExclusionBounds, andAddInclusionBoundsaccurately denote the action they perform, they fall short in specifying the entity upon which the action is executed. It's recommended to include the termComponentin the names of these methods to enhance precision in conveying the entity of the action.By adhering to this naming convention, the gRPC methods will consistently provide clear insight into the entities and actions they concern, contributing to a more comprehensible and user-friendly API documentation.
Proposed solution
The following method names require revision:
AddExclusionBoundsshould be renamed toAddComponentExclusionBounds.AddInclusionBoundsshould be renamed toAddComponentInclusionBounds.SetPowerActiveshould be renamed toSetComponentPowerActive.SetPowerReactiveshould be renamed toSetComponentPowerReactive.Startshould be renamed toStartComponent.HotStandbyshould be renamed toHotStandbyComponent.ColdStandbyshould be renamed toColdStandbyComponent.Stopshould be renamed toStopComponent.By incorporating the term "Component" into these method names, the actions will be distinctly associated with the relevant entity, leading to greater clarity and coherence within the API documentation.
Use cases
No response
Alternatives and workarounds
No response
Additional context
No response