-
Type:
Improvement
-
Resolution: Won't Do
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Server Programmability
-
None
-
None
-
None
-
None
-
None
-
None
-
None
We need to get our story straight server-wide about naming conventions for types.
This is ridiculous:
_mockTickSource = std::make_unique<TickSourceMock<D>>();
It's like the type is TickSourceMock, but when we actually go to make one, we have to acknowledge that it's a "mock tick source". Why not just make that the class name as well?
We have to stick to a convention of English adjective placement or we'll waste time guessing how things are spelled. It's not okay to just put the specifier words willy-nilly at the beginning or the end of the typename depending on mood. (edited)
Some AI search disagrees with me, and maybe a good proportion of my colleages do as well? Doesn't matter. We should decide and commit, to establish predictable naming.
Common Anti-Patterns to Avoid
*The "Specific-First" Trait:
- Naming a class TcpNetworkSocket instead of NetworkSocketTcp breaks the hierarchy. In an IDE dropdown list, Tcp... will be separated from Udp..., destroying logical grouping.
This consideration for IDE dropdowns and intellisense has never held much water with me. Legible names are more important to me.
The "Clean Code" camp says the convention of following natural English speech is more important than IDE autocomplete. So do Python, Go, and Swift style guides, which seem to be taken very seriously by their communities (ok maybe not Python). Rust just says to be consistent (like we very much aren't).