fix: improve formatting for floating-point values in different cultures

[thomhurst]

Fixes #3171 (hopefully!)

[claude]

Claude finished @thomhurst's task —— View job

---

Code Review for PR #3178

Reviewing the floating-point formatting fix for different cultures.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze all changed files
• Review TypedConstantFormatter.cs changes
• Review SpecialFloatingPointValuesHelper.cs changes
• Review new ObjectExtensions.cs file
• Review other modified files
• Assess code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Review security concerns
• Assess test coverage
• Provide comprehensive feedback

Analysis Summary

This PR addresses floating-point formatting issues in different cultures by:

1. Adding ObjectExtensions.ToInvariantString() - New extension method to ensure consistent formatting using InvariantCulture
2. Updating TypedConstantFormatter.cs - Extensive changes to use invariant culture for all numeric formatting
3. Refactoring SpecialFloatingPointValuesHelper.cs - Simplified special floating-point value handling
4. Minor updates to other files to integrate the new culture-aware formatting

Code Quality Assessment

✅ Strengths

1. Comprehensive Culture Fix: The solution properly addresses culture-sensitive numeric formatting across the entire source generator
2. Consistent Approach: Uses InvariantCulture consistently throughout, which is correct for code generation
3. Good Abstraction: The ToInvariantString() extension method provides a clean, reusable solution
4. Performance Conscious: Maintains minimal allocations in hot paths as required by CLAUDE.md
5. Modern C# Usage: Follows the repository's modern C# patterns with expression-bodied members

⚠️ Areas for Improvement

1. Missing Null-Conditional: In ObjectExtensions.cs:12, consider using obj?.ToString() for consistency
2. Documentation: The new extension method could benefit from XML documentation
3. Test Coverage: No visible test additions for the new extension method

Technical Review

ObjectExtensions.cs

// Current - line 12
return obj?.ToString();

// Suggestion: Already uses null-conditional, which is good

TypedConstantFormatter.cs

• Lines 157-292: Excellent systematic replacement of culture-sensitive formatting
• Lines 272-294: Proper use of InvariantCulture for all numeric types
• Performance: No performance regressions - maintains efficient formatting

SpecialFloatingPointValuesHelper.cs

• Significant simplification: Removed 42 lines while maintaining functionality
• Better pattern matching: More concise switch expressions
• Consistent handling: Unified approach for float/double special values

Security & Compatibility

• ✅ No security concerns - Changes are internal to code generation
• ✅ AOT-friendly - Uses culture-invariant formatting suitable for AOT scenarios
• ✅ Thread-safe - InvariantCulture is thread-safe
• ✅ Backward compatible - No breaking API changes

Performance Considerations

• ✅ Minimal allocation impact - Extension method adds negligible overhead
• ✅ Caching preserved - Doesn't affect existing caching strategies
• ✅ Hot path optimization - Critical formatting paths remain efficient

Recommendations

1. Add XML documentation to ObjectExtensions.ToInvariantString():

   /// <summary>
   /// Formats the object using InvariantCulture for consistent code generation.
   /// </summary>
   /// <param name="obj">The object to format</param>
   /// <returns>String representation using InvariantCulture, or null if obj is null</returns>

2. Consider unit tests for the extension method to ensure edge cases are covered

3. Snapshot testing: Verify that source generator snapshots are updated if output format changes

Verdict

✅ APPROVED - This is a well-implemented fix that addresses the core issue properly. The solution is consistent with TUnit's architecture and coding standards. The culture-invariant formatting ensures consistent code generation across different locales, which is exactly what's needed for a source generator.

The changes maintain the dual execution mode requirement and follow performance guidelines. Minor documentation improvements would be beneficial but don't block approval.

---

[claude]

Claude finished @thomhurst's task —— View job

---

Code Review for PR #3178

Reviewing the floating-point formatting fix for different cultures.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze all changed files
• Review TypedConstantFormatter.cs changes
• Review SpecialFloatingPointValuesHelper.cs changes
• Review new ObjectExtensions.cs file
• Review other modified files
• Assess code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Review security concerns
• Assess test coverage
• Provide comprehensive feedback

Analysis Summary

This PR addresses floating-point formatting issues in different cultures by:

1. Adding ObjectExtensions.ToInvariantString() - New extension method to ensure consistent formatting using InvariantCulture
2. Updating TypedConstantFormatter.cs - Extensive changes to use invariant culture for all numeric formatting
3. Refactoring SpecialFloatingPointValuesHelper.cs - Simplified special floating-point value handling
4. Minor updates to other files to integrate the new culture-aware formatting

Code Quality Assessment

✅ Strengths

1. Comprehensive Culture Fix: The solution properly addresses culture-sensitive numeric formatting across the entire source generator
2. Consistent Approach: Uses InvariantCulture consistently throughout, which is correct for code generation
3. Good Abstraction: The ToInvariantString() extension method provides a clean, reusable solution
4. Performance Conscious: Maintains minimal allocations in hot paths as required by CLAUDE.md
5. Modern C# Usage: Follows the repository's modern C# patterns with expression-bodied members

⚠️ Areas for Improvement

1. Missing Null-Conditional: In ObjectExtensions.cs:12, consider using obj?.ToString() for consistency
2. Documentation: The new extension method could benefit from XML documentation
3. Test Coverage: No visible test additions for the new extension method

Technical Review

ObjectExtensions.cs

// Current - line 12
return obj?.ToString();

// Suggestion: Already uses null-conditional, which is good

TypedConstantFormatter.cs

• Lines 157-292: Excellent systematic replacement of culture-sensitive formatting
• Lines 272-294: Proper use of InvariantCulture for all numeric types
• Performance: No performance regressions - maintains efficient formatting

SpecialFloatingPointValuesHelper.cs

• Significant simplification: Removed 42 lines while maintaining functionality
• Better pattern matching: More concise switch expressions
• Consistent handling: Unified approach for float/double special values

Security & Compatibility

• ✅ No security concerns - Changes are internal to code generation
• ✅ AOT-friendly - Uses culture-invariant formatting suitable for AOT scenarios
• ✅ Thread-safe - InvariantCulture is thread-safe
• ✅ Backward compatible - No breaking API changes

Performance Considerations

• ✅ Minimal allocation impact - Extension method adds negligible overhead
• ✅ Caching preserved - Doesn't affect existing caching strategies
• ✅ Hot path optimization - Critical formatting paths remain efficient

Recommendations

1. Add XML documentation to ObjectExtensions.ToInvariantString():

   /// <summary>
   /// Formats the object using InvariantCulture for consistent code generation.
   /// </summary>
   /// <param name="obj">The object to format</param>
   /// <returns>String representation using InvariantCulture, or null if obj is null</returns>

2. Consider unit tests for the extension method to ensure edge cases are covered

3. Snapshot testing: Verify that source generator snapshots are updated if output format changes

Verdict

✅ APPROVED - This is a well-implemented fix that addresses the core issue properly. The solution is consistent with TUnit's architecture and coding standards. The culture-invariant formatting ensures consistent code generation across different locales, which is exactly what's needed for a source generator.

The changes maintain the dual execution mode requirement and follow performance guidelines. Minor documentation improvements would be beneficial but don't block approval.

---