More style updates

style.md

@@ -75,8 +75,9 @@ uint32_t initial_block_size_;
 ### Structs
 - **PascalCase** for struct names
 - **Always use struct** - eliminates debates about complexity and maintains consistency
-- **Public members first, private after** - leverages struct's default public access
-- Use `private:` sections when encapsulation is needed
+- **Public members first, private after** - puts the interface users care about at the top, implementation details below
+- **Full encapsulation still applies** - use `private:` sections to hide implementation details and maintain deep, capable classes
+- The struct keyword doesn't mean shallow design - it means interface-first organization for human readers
 ```cpp
 struct ArenaAllocator {
   // Public interface first
@@ -253,6 +254,7 @@ for (auto &precondition : preconditions_) {
 - **Prefer unique_ptr** for exclusive ownership
 - **shared_ptr only if shared ownership is necessary** - most objects have single owners
 - **Factory patterns** for complex construction and ownership control
+- **STL containers with arena allocators require default construction after arena reset** - `clear()` is not sufficient
 ```cpp
 // Static factory methods for complex objects requiring specific initialization
 auto server = Server::create(config, handler);  // Ensures shared_ptr semantics
@@ -271,6 +273,12 @@ private:
 
 // Usage in Server
 auto conn = std::unique_ptr<Connection>(new Connection(args));
+
+// STL containers with arena allocators - correct reset pattern
+std::vector<Operation, ArenaStlAllocator<Operation>> operations(arena_alloc);
+// ... use container ...
+operations = {};  // Default construct - clear() won't work correctly
+arena.reset();  // Reset arena memory
 ```
 
 ### Resource Management
@@ -383,8 +391,8 @@ TEST_CASE("ArenaAllocator basic allocation") {
 - **Prefer testing through public interfaces** - focus on observable behavior rather than implementation details
 - **Test the contract, not the implementation** - validate what the API promises to deliver
 - **Avoid testing private methods directly** - if private functionality needs testing, consider if it should be public or extracted
-- **Integration over isolation** - test components working together when practical
-- **Mock only external dependencies** - prefer real implementations for internal components
+- **Both integration and unit tests** - test components in isolation and working together
+- **Prefer fakes to mocks** - use real implementations for internal components, fake external dependencies
 ```cpp
 // Good: Testing through public API
 TEST_CASE("Server accepts connections") {