# Source Code Logging Implementation Critic Framework

This framework guides the Critic role when evaluating logging implementations within source code files. This critic focuses on effective logging practices, appropriate log levels, meaningful context, structured data, and operational value that ensure logging provides actionable insights for debugging, monitoring, and incident investigation.

## Source Code Logging Evaluation Areas

### 1. Log Placement and Timing
**What to Look For:**
- Logging at appropriate points in code execution flow
- Logging before and after critical operations
- Logging of entry/exit points for important functions
- Logging of state changes and decision points
- Logging of error conditions and exceptional cases

**Common Problems:**
- Missing logs at critical decision points or state changes
- Logging too early or too late in execution flow
- Inconsistent logging patterns across similar operations
- Missing logs for error conditions and edge cases
- Over-logging of trivial operations

**Evaluation Questions:**
- Are logs placed at appropriate points in the execution flow?
- Are critical operations and state changes properly logged?
- Are error conditions and exceptional cases logged?
- Is there consistent logging across similar operations?
- Are entry/exit points logged for important functions?

### 2. Log Level Appropriateness
**What to Look For:**
- Appropriate use of ERROR, WARN, INFO, DEBUG log levels
- ERROR level for actual errors that need immediate attention
- WARN level for concerning but non-fatal issues
- INFO level for important business events and state changes
- DEBUG level for detailed troubleshooting information

**Common Problems:**
- Using ERROR level for non-error conditions
- Using INFO level for debug information
- Missing ERROR logs for actual error conditions
- Inconsistent log level usage across similar operations
- Overuse of DEBUG level in production code

**Evaluation Questions:**
- Are log levels used appropriately for the severity of events?
- Are actual errors logged at ERROR level?
- Is DEBUG level used only for troubleshooting information?
- Is there consistent log level usage across similar operations?
- Are WARN logs used for concerning but non-fatal issues?

### 3. Context and Information Quality
**What to Look For:**
- Sufficient context for effective debugging and analysis
- Relevant identifiers (user ID, request ID, session ID, etc.)
- Meaningful error messages with actionable information
- State information that helps understand the context
- Correlation data for distributed operations

**Common Problems:**
- Generic error messages without specific context
- Missing identifiers needed for correlation
- Insufficient state information for debugging
- Vague or unhelpful log messages
- Missing correlation data for distributed operations

**Evaluation Questions:**
- Do log messages include sufficient context for debugging?
- Are relevant identifiers included (user ID, request ID, etc.)?
- Do error messages provide actionable information?
- Is state information included when relevant?
- Are correlation IDs included for distributed operations?

### 4. Structured Data and Formatting
**What to Look For:**
- Consistent log message structure and format
- Structured data fields for automated parsing
- Proper escaping of special characters
- Consistent field naming conventions
- Machine-readable data formats

**Common Problems:**
- Inconsistent log message formats
- Unstructured text that's difficult to parse
- Missing or inconsistent field names
- Poor escaping of special characters
- Non-machine-readable data formats

**Evaluation Questions:**
- Are log messages structured consistently?
- Is data formatted for automated parsing?
- Are field names consistent and meaningful?
- Are special characters properly escaped?
- Is the format machine-readable?

### 5. Performance and Resource Impact
**What to Look For:**
- Efficient log message construction
- Conditional logging for expensive operations
- Proper use of log level filtering
- Minimal impact on application performance
- Appropriate use of structured logging

**Common Problems:**
- Expensive operations in log message construction
- Logging in tight loops without level checks
- Inefficient string concatenation for log messages
- Logging sensitive or large data structures
- Performance impact from excessive logging

**Evaluation Questions:**
- Are log messages constructed efficiently?
- Is conditional logging used for expensive operations?
- Are log level checks used in performance-critical code?
- Does logging have minimal impact on performance?
- Is sensitive data properly handled in logs?

## Source Code Logging Criticism Guidelines

### Focus on Logging Effectiveness
**Good Criticism:**
- "Missing ERROR log after database connection failure makes debugging impossible"
- "Generic 'operation failed' message provides no actionable information"
- "Logging user password in DEBUG message creates security vulnerability"
- "Missing correlation ID makes distributed transaction tracing impossible"

**Poor Criticism:**
- "This logging isn't good enough"
- "The log message could be better"
- "This doesn't provide enough information"

### Emphasize Context and Debugging Value
**Good Criticism:**
- "Log message 'error occurred' provides no context for debugging"
- "Missing user ID in authentication log prevents user-specific investigation"
- "No state information logged before critical operation failure"
- "Missing request ID makes correlation across services impossible"

**Poor Criticism:**
- "This context is insufficient"
- "More information would be helpful"
- "This logging lacks detail"

### Consider Operational Impact
**Good Criticism:**
- "Logging entire user object in DEBUG creates performance and security issues"
- "Missing log level check in tight loop causes 50% performance degradation"
- "String concatenation in log message creates unnecessary object allocation"
- "Logging sensitive data violates security requirements"

**Poor Criticism:**
- "This might cause performance issues"
- "Security could be a concern"
- "This logging is inefficient"

## Source Code Logging Evaluation Questions

### For Any Logging Implementation
1. **Are logs placed at appropriate points in the execution flow?**
2. **Are log levels used appropriately for the severity of events?**
3. **Do log messages include sufficient context for debugging?**
4. **Are log messages structured consistently?**
5. **Are log messages constructed efficiently?**
6. **Are critical operations and state changes properly logged?**
7. **Are error conditions and exceptional cases logged?**
8. **Are relevant identifiers included (user ID, request ID, etc.)?**
9. **Is conditional logging used for expensive operations?**
10. **Are correlation IDs included for distributed operations?**

### For Error Handling
1. **Are actual errors logged at ERROR level?**
2. **Do error messages provide actionable information?**
3. **Is sufficient context included with error logs?**
4. **Are error conditions logged before and after handling?**
5. **Are stack traces or error details included when appropriate?**

### For Business Logic
1. **Are important business events logged at INFO level?**
2. **Are state changes and decision points logged?**
3. **Is user activity logged with appropriate identifiers?**
4. **Are critical operations logged before and after execution?**
5. **Is there consistent logging across similar business operations?**

### For Performance-Critical Code
1. **Are log level checks used before expensive operations?**
2. **Is conditional logging used for debug information?**
3. **Are log messages constructed efficiently?**
4. **Is sensitive data properly handled in logs?**
5. **Does logging have minimal impact on performance?**

## Source Code Logging Principles Applied

### "Log What Matters"
- Log critical operations and state changes
- Log error conditions with sufficient context
- Log important business events and decisions
- Don't log trivial or obvious operations

### "Provide Context"
- Include relevant identifiers and correlation data
- Provide sufficient state information for debugging
- Use meaningful error messages with actionable information
- Include context that helps understand the situation

### "Use Appropriate Levels"
- ERROR for actual errors that need immediate attention
- WARN for concerning but non-fatal issues
- INFO for important business events and state changes
- DEBUG for detailed troubleshooting information

### "Structure for Analysis"
- Use consistent log message formats
- Include structured data for automated parsing
- Use consistent field naming conventions
- Provide machine-readable data formats

### "Consider Performance"
- Construct log messages efficiently
- Use conditional logging for expensive operations
- Check log levels before expensive operations
- Avoid logging sensitive or large data structures

### "Enable Debugging"
- Log entry/exit points for important functions
- Log before and after critical operations
- Include correlation data for distributed operations
- Provide sufficient detail for effective troubleshooting