* feat(agents): implement category-based agent organization system - Organize agents into domain categories (core, development, content, data, product, learning) - Move 10 agents to category subdirectories with proper git rename tracking - Update 13 subagents with category and type metadata in frontmatter - Add category metadata files (0-category.json) documenting common patterns - Implement local registry fallback in install script for offline development - Add comprehensive validation suite with 15 automated tests (100% pass rate) - Enhance registry validation with duplicate ID and consistency checks - Update eval framework with intelligent path resolution (backward compatible) - Archive legacy eval structure to _archive/ for reference - Update all documentation to reflect category-based structure - Bump version to 0.5.0 with accurate CHANGELOG Technical Details: - 23 agents organized (10 category agents, 13 subagents) - 6 category directories created - Path resolution supports both agent IDs and category paths - Registry schema updated to v2.0.0 - 159 files changed, 872 insertions(+), 10738 deletions(-) BREAKING CHANGE: Agent file paths now use category structure. Update references from .opencode/agent/openagent.md to .opencode/agent/core/openagent.md. Eval framework maintains backward compatibility via path resolution. * refactor(evals): consolidate documentation and enhance test infrastructure - Remove temporary project tracking files (PHASE_5_COMPLETE, PROJECT_COMPLETE, etc.) - Consolidate evaluation framework docs into main README - Enhance test execution with improved logging and multi-prompt support - Move system-builder from core to meta category - Add comprehensive test suites for openagent with organized structure - Create evaluation test structure for all subagents - Clean up archived workflows and redundant documentation - Update registry to reflect new agent organization - Add shared test templates and golden test patterns * feat(ci): add manual trigger support for bot-created PRs in validate-registry workflow - Add pr_number input to workflow_dispatch for manually triggering validation - Fetch PR details dynamically when triggered manually - Support both automatic (PR event) and manual (workflow_dispatch) triggers - Enable validation of bot-created PRs like automated version bumps - Update branch detection and push logic to handle both trigger types - Add documentation explaining how to manually trigger for bot PRs * feat(evals): add explicit context file validation to test framework - Add expectedContextFiles field to test YAML schema for explicit context file specification - Enhance context-loading-evaluator to support both auto-detect and explicit validation modes - Update documentation with comprehensive guide and examples - Clean up archived legacy test structure (90+ old test files) - Add new example tests demonstrating explicit context validation - Backward compatible with existing tests * feat(evals): add multi-agent logging system and performance optimizations Implement comprehensive multi-agent logging and performance improvements for the eval framework. Task 01: Multi-Agent Logging System - Add complete hierarchical logging module (evals/framework/src/logging/) - SessionTracker: tracks parent-child delegation hierarchies - MultiAgentLogger: pretty-prints logs with visual indentation - Formatters: box characters and emoji formatting - 37 passing unit tests (session-tracker, logger, integration) - Integrate with SDK event stream handler - Hook into session.created, message.updated, message.part.updated events - Real-time child session detection via timestamp heuristics - Message deduplication for cleaner output - Enable in debug mode only (<1% performance overhead) - Add demo script and comprehensive documentation Task 02: Performance Optimizations - Reduce grace period from 5s to 2s (67% reduction, 10-20% faster tests) - Add PerformanceMetricsEvaluator for bottleneck identification - Collects tool latencies, inference time, idle time - Provides full performance visibility - Update smoke test to validate delegation (core feature) - Replace simple read test with multi-agent delegation test - Tests both parent and child agent functionality - Validates multi-agent logging system Results: - 37 unit tests passing - Smoke test passing (95/100 score) - Clean hierarchical logging output - 10-20% faster test execution - Full multi-agent visibility Files changed: 16 files, +2678 lines Time saved: ~6-8 days (completed in 6 hours vs 3-5 day estimate) * feat(evals): show child agent execution in non-debug mode - Enable MultiAgentLogger in both debug and non-debug modes - Add verbose parameter to control output level - Non-verbose mode shows concise child session lifecycle: - Child agent started message - Child agent completed with duration - Verbose mode (--debug) shows full delegation hierarchy - Update documentation to reflect new behavior This provides visibility into delegation without overwhelming output, giving confidence that child agents are actually running. * feat(evals): improve delegation testing and behavior validation Major improvements to eval framework: Test Suite: - Add 00-smoke-test.yaml (basic read operation) - Rename 01-smoke-test.yaml → 02-delegation-test.yaml (delegation test) - Add simple-responder test agent for delegation testing - Add debug test: simple-subagent-call.yaml Evaluators: - Add agent-model-evaluator.ts for agent/model validation - Enhance behavior-evaluator.ts with detailed task tool output - Improve delegation-evaluator.ts with better evidence tracking Schema & Execution: - Add expectedAgent and expectedModel to test schema - Improve test executor with better logging and error handling Documentation: - Update evals/README.md with new features and performance improvements - Remove outdated MULTI_AGENT_LOGGING_COMPLETE.md Registry: - Add simple-responder test agent to registry Fixes: - Fix dashboard.sh path resolution These changes provide better visibility into delegation, improved test coverage, and clearer validation of agent behavior. * chore: add GitHub Actions workflow and plugin documentation - Add .github/workflows/evals/run-evaluations.yml for automated eval testing - Add dev/ai-tools/opencode/plugins/Plugin-inspiration.md for plugin development reference
176 lines
4.5 KiB
Markdown
176 lines
4.5 KiB
Markdown
# Clean Code Principles
|
|
|
|
**Category**: development
|
|
**Purpose**: Core coding standards and best practices for writing clean, maintainable code
|
|
**Used by**: frontend-specialist, backend-specialist, devops-specialist, codebase-agent
|
|
|
|
---
|
|
|
|
## Overview
|
|
|
|
Clean code is code that is easy to read, understand, and maintain. It follows consistent patterns, uses meaningful names, and is well-organized. This guide provides principles and patterns for writing clean code across all languages.
|
|
|
|
## Core Principles
|
|
|
|
### 1. Meaningful Names
|
|
|
|
**Use intention-revealing names**:
|
|
- Variable names should reveal intent
|
|
- Function names should describe what they do
|
|
- Class names should describe what they represent
|
|
|
|
**Examples**:
|
|
```javascript
|
|
// Bad
|
|
const d = new Date();
|
|
const x = getUserData();
|
|
|
|
// Good
|
|
const currentDate = new Date();
|
|
const activeUserProfile = getUserData();
|
|
```
|
|
|
|
### 2. Functions Should Do One Thing
|
|
|
|
**Single Responsibility**:
|
|
- Each function should have one clear purpose
|
|
- Functions should be small (ideally < 20 lines)
|
|
- Extract complex logic into separate functions
|
|
|
|
**Example**:
|
|
```javascript
|
|
// Bad
|
|
function processUser(user) {
|
|
validateUser(user);
|
|
saveToDatabase(user);
|
|
sendEmail(user);
|
|
logActivity(user);
|
|
}
|
|
|
|
// Good
|
|
function processUser(user) {
|
|
const validatedUser = validateUser(user);
|
|
const savedUser = saveUserToDatabase(validatedUser);
|
|
notifyUser(savedUser);
|
|
return savedUser;
|
|
}
|
|
```
|
|
|
|
### 3. Avoid Deep Nesting
|
|
|
|
**Keep nesting shallow**:
|
|
- Use early returns
|
|
- Extract nested logic into functions
|
|
- Prefer guard clauses
|
|
|
|
**Example**:
|
|
```javascript
|
|
// Bad
|
|
function processOrder(order) {
|
|
if (order) {
|
|
if (order.items.length > 0) {
|
|
if (order.total > 0) {
|
|
// process order
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
// Good
|
|
function processOrder(order) {
|
|
if (!order) return;
|
|
if (order.items.length === 0) return;
|
|
if (order.total <= 0) return;
|
|
|
|
// process order
|
|
}
|
|
```
|
|
|
|
### 4. DRY (Don't Repeat Yourself)
|
|
|
|
**Eliminate duplication**:
|
|
- Extract common logic into reusable functions
|
|
- Use composition over inheritance
|
|
- Create utility functions for repeated patterns
|
|
|
|
### 5. Error Handling
|
|
|
|
**Handle errors explicitly**:
|
|
- Use try-catch for expected errors
|
|
- Provide meaningful error messages
|
|
- Don't ignore errors silently
|
|
|
|
**Example**:
|
|
```javascript
|
|
// Bad
|
|
function fetchData() {
|
|
try {
|
|
return api.getData();
|
|
} catch (e) {
|
|
return null;
|
|
}
|
|
}
|
|
|
|
// Good
|
|
async function fetchData() {
|
|
try {
|
|
return await api.getData();
|
|
} catch (error) {
|
|
logger.error('Failed to fetch data', { error });
|
|
throw new DataFetchError('Unable to retrieve data', { cause: error });
|
|
}
|
|
}
|
|
```
|
|
|
|
## Best Practices
|
|
|
|
1. **Write self-documenting code** - Code should explain itself through clear naming and structure
|
|
2. **Keep functions pure when possible** - Avoid side effects, return new values instead of mutating
|
|
3. **Use consistent formatting** - Follow language-specific style guides (Prettier, ESLint, etc.)
|
|
4. **Write tests first** - TDD helps design better APIs and catch issues early
|
|
5. **Refactor regularly** - Improve code structure as you learn more about the domain
|
|
6. **Comment why, not what** - Code shows what, comments explain why
|
|
7. **Use type systems** - TypeScript, type hints, or static analysis tools
|
|
8. **Favor composition** - Build complex behavior from simple, reusable pieces
|
|
|
|
## Anti-Patterns
|
|
|
|
- ❌ **Magic numbers** - Use named constants instead of hardcoded values
|
|
- ❌ **God objects** - Classes that do too much or know too much
|
|
- ❌ **Premature optimization** - Optimize for readability first, performance second
|
|
- ❌ **Clever code** - Simple and clear beats clever and complex
|
|
- ❌ **Long parameter lists** - Use objects or configuration patterns instead
|
|
- ❌ **Boolean flags** - Often indicate a function doing multiple things
|
|
- ❌ **Mutable global state** - Leads to unpredictable behavior and bugs
|
|
|
|
## Language-Specific Guidelines
|
|
|
|
### JavaScript/TypeScript
|
|
- Use `const` by default, `let` when needed, never `var`
|
|
- Prefer arrow functions for callbacks
|
|
- Use async/await over raw promises
|
|
- Destructure objects and arrays for clarity
|
|
|
|
### Python
|
|
- Follow PEP 8 style guide
|
|
- Use list comprehensions for simple transformations
|
|
- Prefer context managers (`with` statements)
|
|
- Use type hints for function signatures
|
|
|
|
### Go
|
|
- Follow effective Go guidelines
|
|
- Use defer for cleanup
|
|
- Handle errors explicitly
|
|
- Keep interfaces small
|
|
|
|
### Rust
|
|
- Embrace ownership and borrowing
|
|
- Use pattern matching
|
|
- Prefer iterators over loops
|
|
- Handle errors with Result types
|
|
|
|
## References
|
|
|
|
- Clean Code by Robert C. Martin
|
|
- The Pragmatic Programmer by Hunt & Thomas
|
|
- Refactoring by Martin Fowler
|