Coding Standards
This document outlines the coding standards and best practices for the Rhesis project. Following these standards ensures code quality, maintainability, and consistency across the codebase.
Code Quality Matters Consistent coding standards help us maintain high-quality code, improve collaboration, and reduce bugs. Please follow these guidelines for all contributions.
Python Standards
Code Style
We follow PEP 8 and use Ruff for automatic formatting and linting.
Basic Rules:
- Indentation: 4 spaces (no tabs)
- Line Length: 88 characters maximum
- Naming:
snake_casefor variables, functions, and modules - Classes:
PascalCasefor class names - Constants:
UPPER_CASEfor constants
Type Hints
All functions should include type hints:
Docstrings
Use Google-style docstrings for all functions and classes:
Error Handling
Use specific exceptions and proper error handling:
Testing Standards
Unit Tests
Test individual functions and methods in isolation.
Integration Tests
Test component interactions and API endpoints.
Fixtures
Use pytest fixtures for test data and setup.
Coverage
Maintain 90%+ test coverage for new code.
Mocking
Mock external dependencies and services.
Example Test:
JavaScript/TypeScript Standards
Code Style
We use ESLint and Prettier for code formatting and linting.
Basic Rules:
- Indentation: 2 spaces
- Line Length: 80 characters maximum
- Naming:
camelCasefor variables and functions - Components:
PascalCasefor React components - Constants:
UPPER_SNAKE_CASEfor constants
TypeScript Usage
Use TypeScript for all new code with strict configuration:
React Components
Follow React best practices and hooks:
Custom Hooks
Create reusable custom hooks for common functionality:
Error Handling
Implement proper error boundaries and error handling:
General Best Practices
Code Organization
File Structure
Organize files logically and consistently.
Separation of Concerns
Keep functions and components focused and single-purpose.
DRY Principle
Don’t Repeat Yourself - extract common functionality.
SOLID Principles
Follow object-oriented design principles.
Clean Code
Write readable, self-documenting code.
Performance Considerations
Security Best Practices
Security Guidelines - Always validate and sanitize user input - Use parameterized queries to prevent SQL injection - Implement proper authentication and authorization - Keep dependencies updated and scan for vulnerabilities - Never expose sensitive information in logs or error messages
Documentation Standards
Code Comments:
- Write comments for complex logic
- Explain “why” not “what”
- Keep comments up to date with code changes
README Files:
- Include setup instructions
- Document API usage
- Provide examples
API Documentation:
- Use OpenAPI/Swagger for backend APIs
- Include request/response examples
- Document error codes and messages
Pre-commit Hooks
We use pre-commit hooks to enforce code quality:
Code Review Checklist
When reviewing code, check for:
Functionality
Does the code work as intended?
Code Quality
Is the code readable and maintainable?
Testing
Are there adequate tests?
Documentation
Is the code well-documented?
Performance
Are there performance implications?
Security
Are there security concerns?
Questions? If you have questions about these coding standards: - Check our Development Setup Guide - Ask in GitHub Discussions - Review existing code for examples