71 lines
2.1 KiB
Markdown
71 lines
2.1 KiB
Markdown
# Global Code Style Guide
|
|
|
|
This document outlines coding standards and conventions for all projects in MyWorkspace.
|
|
|
|
## General Principles
|
|
|
|
- **Readability**: Code should be easy to read and understand
|
|
- **Consistency**: Follow established patterns within each project
|
|
- **Simplicity**: Prefer simple solutions over complex ones
|
|
- **Self-Documenting**: Use clear naming to make code self-explanatory
|
|
|
|
## Formatting
|
|
|
|
### Whitespace
|
|
- Use consistent indentation (2 or 4 spaces, match project conventions)
|
|
- Add blank lines between logical sections
|
|
- Avoid trailing whitespace
|
|
|
|
### Line Length
|
|
- Keep lines reasonable (typically under 100-120 characters)
|
|
- Break long statements across multiple lines when needed
|
|
|
|
### File Organization
|
|
- Group related functionality together
|
|
- Use meaningful file names
|
|
- Keep files focused on a single purpose
|
|
|
|
## Naming Conventions
|
|
|
|
### Variables and Functions
|
|
- Use `camelCase` for variables and functions in most languages
|
|
- Use `PascalCase` for classes and types
|
|
- Use `SCREAMING_SNAKE_CASE` for constants
|
|
- Choose descriptive names that reveal intent
|
|
|
|
### Files
|
|
- Use descriptive, lowercase names with hyphens or underscores
|
|
- Match naming conventions to language best practices
|
|
|
|
## Code Structure
|
|
|
|
### Functions
|
|
- Keep functions short and focused
|
|
- Limit function parameters (aim for 3 or fewer)
|
|
- Follow the Single Responsibility Principle
|
|
|
|
### Classes
|
|
- Keep classes cohesive with related responsibilities
|
|
- Use clear, descriptive class names
|
|
- Consider single inheritance over deep hierarchies
|
|
|
|
### Error Handling
|
|
- Handle errors gracefully with appropriate messages
|
|
- Use exceptions for exceptional cases
|
|
- Log errors with sufficient context for debugging
|
|
|
|
## Comments
|
|
|
|
- Write comments to explain *why*, not *what*
|
|
- Keep comments up to date with code changes
|
|
- Document complex business logic
|
|
- Use docstrings for public APIs
|
|
|
|
## Project-Specific Variations
|
|
|
|
Individual projects may have their own style guides that extend or override these guidelines. Always check the project's `STEERING.md` for specific requirements.
|
|
|
|
---
|
|
|
|
*This is a living document. Update it as best practices evolve.*
|