Decompose complex functions exceeding 100 lines

[cgrindel]

Summary

Several critical functions in the codebase exceed 100 lines and handle multiple responsibilities, making them difficult to test, understand, and maintain. These need to be decomposed into smaller, focused functions.

Functions Requiring Decomposition

Critical Priority

1. dependency_index.go:ResolveModulesToProducts (294 lines)

   • Current: Handles direct resolution, transitive resolution, and builtin modules in one function
   • Suggested: Break into resolveToDirectProducts, resolveToTransitiveProducts, resolveToBuiltinModules

2. package_info.go:NewPackageInfo (149 lines)

   • Current: Handles multiple responsibilities (parsing, validation, dependency resolution)
   • Suggested: Extract validation, dependency parsing, and data merging into separate functions

3. generate.go:genRulesFromSrcFiles (82 lines)

   • Current: Handles proto rules, source collection, and rule generation
   • Suggested: Extract proto rule generation and source file processing

Proposed Refactoring Approach

Example for ResolveModulesToProducts:

func (di *DependencyIndex) ResolveModulesToProducts(modules []string, pkgIdentities []string) ResolutionResult {
    result := NewResolutionResult()
    result = di.resolveToDirectProducts(modules, pkgIdentities, result)
    result = di.resolveToTransitiveProducts(result)
    result = di.resolveToBuiltinModules(result)
    return result
}

func (di *DependencyIndex) resolveToDirectProducts(modules []string, pkgIdentities []string, result ResolutionResult) ResolutionResult {
    // Focused logic for direct product resolution
}

func (di *DependencyIndex) resolveToTransitiveProducts(result ResolutionResult) ResolutionResult {
    // Focused logic for transitive product resolution
}

Acceptance Criteria

• All functions are under 100 lines
• Each function has a single, clear responsibility
• Extracted functions are properly documented
• All existing tests continue to pass
• New functions have appropriate unit tests
• Performance is maintained or improved

Benefits

• Testability: Smaller functions are easier to unit test
• Readability: Clearer intent and easier to understand
• Maintainability: Easier to modify individual pieces of logic
• Reusability: Extracted functions may be useful elsewhere
• Debugging: Easier to isolate and fix issues

Implementation Notes

1. Preserve existing behavior - this is a refactoring, not a feature change
2. Add tests for new functions before and after extraction
3. Use descriptive function names that clearly indicate purpose
4. Consider performance implications of function call overhead
5. Update documentation to reflect new structure