Fix API docs for `Commands` methods
Objective
The doc comments for Command methods are a bit inconsistent on the format, they sometimes go out of scope, and most importantly they are wrong, in the sense that they claim to perform the action described by the command, while in reality, they just push a command to perform the action.
- Follow-up of #5938.
- Related to #5913.
Solution
- Where applicable, only stated that a
Commandis pushed. - Added a “See also” section for similar methods.
- Added a missing “Panics” section for
Commands::entity. - Removed a wrong comment about
Commands::get_or_spawnreturningNone(It does not return an option). - Removed polluting descriptions of other items.
- Misc formatting changes.
Future possibilities
Since the Command implementors (Spawn, InsertBundle, InitResource, ...) are public, I thought that it might be appropriate to describe the action of the command there instead of the method, and to add a method → command struct link to fill the gap.
If that seems too far-fetched, we may opt to make them private, if possible, or #[doc(hidden)].
@wilk10 I just added “to the queue”, since “Pushes a Command to the command queue” sounds a little too repetitive.
Tests in code should make explicit what functionality is expected. (Code is law?)
Tests in code should make explicit what functionality is expected. (Code is law?)
What do you mean? I'm not touching tests here.
I mean someone ought to write tests for the Commands methods to demonstrate how they ought to work. The documentation can be incorrect/misleading, but having code which demonstrates the intention of how Commands is expected to work is worth even more than solely changing the documentation.
For example, if the Commands are actually applied at a certain Stage of the overall ECS system's operation, a set of tests could make that clear. I have no objection to your PR.
Pull request successfully merged into main.
Build succeeded: