There's a need to expand guidelines around making critical logic and edge cases more explicit in Go code. Currently, the style guide touches on this but could benefit from more detailed patterns and examples.

Key points to address:

1. Best practices for decomposing complex boolean expressions (like the leap year example) into named variables
2. Guidelines for helper functions that contain critical business logic
3. Patterns for making edge cases more visible and maintainable
4. Documentation requirements for code containing non-obvious behavior

This would help:

• Improve code maintainability
• Make critical logic more discoverable
• Reduce chances of introducing bugs during future modifications
• Help newcomers understand important edge cases

Example of current guidance that could be expanded:

// Instead of:
leap := (year%4 == 0) && (!(year%100 == 0) || (year%400 == 0))

// Prefer:
var (
    leap4   = year%4 == 0
    leap100 = year%100 == 0
    leap400 = year%400 == 0
)
leap := leap4 && (!leap100 || leap400)