|
| 1 | +# Use plural for modules containing collections of types |
| 2 | + |
| 3 | +## Description |
| 4 | + |
| 5 | +In Rust, the naming conventions for module names (mod names) generally lean |
| 6 | +towards using the singular form, rather than plurals. This practice aligns with |
| 7 | +Rust's emphasis on clarity and precision in code organization. The idea is that |
| 8 | +a module name should represent a single concept or functionality, which often |
| 9 | +means using a singular noun to describe what the module contains or does. |
| 10 | + |
| 11 | +However, it's important to note that conventions can vary depending on the |
| 12 | +context or the specific project. Some projects may choose to use plural forms |
| 13 | +for module names if they feel it more accurately represents the contents of the |
| 14 | +module. For example, a module that contains multiple implementations of a |
| 15 | +similar concept or utility functions related to a specific theme might be named |
| 16 | +in the plural to reflect the diversity of its contents. |
| 17 | + |
| 18 | +This could have some pros anc cons. For example, for a module containing types of |
| 19 | +requests you could refer to a concrete request with `request::Announce` or |
| 20 | +`requests::Announce`. If you read a code line `request::Announce` is probably |
| 21 | +better. However, if you read the filed or folder name `requests`gives you a |
| 22 | +better idea of what the modules contains. |
| 23 | + |
| 24 | +## Agreement |
| 25 | + |
| 26 | +We agree on use plural in cases where the modules contain some types with the |
| 27 | +same type of responsibility. For example: |
| 28 | + |
| 29 | +- `src/servers`. |
| 30 | +- `src/servers/http/v1/requests`. |
| 31 | +- `src/servers/http/v1/responses`. |
| 32 | +- `src/servers/http/v1/services`. |
| 33 | +- Etcetera. |
| 34 | + |
| 35 | +We will change them progressively. |
0 commit comments