# Code Style Guidelines ## General Principles - Write clean, readable, and maintainable code - Follow the DRY (Don't Repeat Yourself) principle - Aim for simplicity and clarity over cleverness - Comment your code appropriately, but prefer self-documenting code - Consistent naming conventions throughout the codebase ## Naming Conventions ### Variables - Use meaningful, descriptive names - camelCase for variables in JavaScript/TypeScript - snake_case for variables in Python - Avoid single-letter variables except for counters or coordinates ### Functions - Use verb phrases that describe what the function does - camelCase for function names in JavaScript/TypeScript - snake_case for function names in Python - Keep functions small and focused on a single task ### Classes - Use PascalCase for class names - Class names should be nouns - Use descriptive names that reflect the class's responsibility ### Constants - Use UPPER_SNAKE_CASE for constants - Define constants at the top of files or in dedicated constants files ## Formatting ### Indentation - Use 2 spaces for JavaScript/TypeScript - Use 4 spaces for Python - Be consistent with indentation throughout files ### Line Length - Maximum 80-100 characters per line - Break long lines at logical points ### Spacing - Use spaces around operators - One space after commas - No space after function names in function calls - One space after keywords like if, for, while ## Language-Specific Guidelines ### JavaScript/TypeScript - Use const and let instead of var - Use template literals instead of string concatenation - Use arrow functions for anonymous functions - Use async/await over Promises when possible - Use destructuring assignment when appropriate - Use spread operator (...) instead of Object.assign() ### React - Component names should be PascalCase - One component per file - Use functional components with hooks over class components - Use named exports for components - Keep components small and focused ### CSS/SCSS - Use kebab-case for CSS class names - Use a consistent methodology (BEM, SMACSS, etc.) - Organize properties alphabetically or by type - Use variables for repeated values (colors, spacing, etc.) ## Documentation ### Comments - Use JSDoc-style comments for functions and classes - Comment complex logic or non-obvious solutions - Avoid commented-out code in production - Keep comments up-to-date with code changes ### README - Include clear installation and setup instructions - Document available scripts/commands - Provide basic usage examples - List dependencies and requirements ## Testing - Write tests for all new features - Maintain high test coverage - Use descriptive test names that explain what they're testing - Follow the Arrange-Act-Assert pattern - Keep tests independent and isolated ## Version Control - Write clear, descriptive commit messages - Use present tense in commit messages - Reference issue numbers in commit messages - Make small, focused commits - Pull/merge request descriptions should explain the change and why it's needed ## Code Review - Review code for clarity, correctness, and consistency - Focus on the code, not the person - Provide constructive feedback - Suggest improvements, not just point out problems - Check for security vulnerabilities and performance issues ## Linting and Formatting - Use ESLint for JavaScript/TypeScript - Use Prettier for automatic formatting - Run linters as part of CI/CD pipeline - Fix linting errors before merging code Remember, these guidelines are meant to help, not hinder. The primary goal is readable, maintainable code that the whole team can work with effectively.