-
Type: Technical Debt
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Storage Engines
-
StorEng - Defined Pipeline
As part of the Q3 modularization effort, the decision was made to place module-private function declarations and structs in a dedicated *_private.h file.
Review this decision by considering the pros and cons, and then make a more informed, evidence-backed decision.
Potential points to consider:
Pros:
- Storing private declarations in a separate file improves code organization by clearly separating internal implementation details from the public API
- It's easier to understand the public API of a module without being overwhelmed by internal details.
- Changes module's internals are localized to module-private files.
Cons:
- Creating a separate *_private.h file for every module increases the number of files in the project, which can make it harder to navigate.
- For smaller modules that may only have a few internal functions or structures, creating a separate file adds unnecessary complexity.
- When the visibility of a function or struct needs to change, moving the code between *_private.h and the public header file requires to physically relocate code. Code movement is hard to track. It can be a source of errors. It's also a distraction from the main purpose of a PR.
An alternative would be to keep both public and private declarations in the same file but clearly mark sections for public and private declarations within the same header file.
We could use it for smaller modules while bigger ones could use a *_private.h if it improves code structure and clarity.
- is related to
-
WT-13635 The `prototypes` dist script should respect functions' and structs' privacy declaration.
- Backlog