|
| 1 | +# Style Guide |
| 2 | + |
| 3 | +This document outlines the coding style and conventions used in the snap-7715-permissions project. |
| 4 | + |
| 5 | +## General |
| 6 | + |
| 7 | +- Use UTF-8 encoding for all files |
| 8 | +- Use 2 spaces for indentation |
| 9 | + |
| 10 | +## TypeScript/JavaScript |
| 11 | + |
| 12 | +### Naming Conventions |
| 13 | + |
| 14 | +- Use camelCase for variables, functions, and method names |
| 15 | +- Use camelCase for file names |
| 16 | + |
| 17 | +### Documentation |
| 18 | + |
| 19 | +- Use JSDoc comments for public APIs |
| 20 | +- Include descriptions for parameters and return values |
| 21 | +- Document thrown exceptions |
| 22 | + |
| 23 | +Example: |
| 24 | +```typescript |
| 25 | +/** |
| 26 | + * Description of the function. |
| 27 | + * |
| 28 | + * @param options - The options object. |
| 29 | + * @param options.param1 - Description of param1. |
| 30 | + * @returns Description of the return value. |
| 31 | + * @throws When something goes wrong. |
| 32 | + */ |
| 33 | +``` |
| 34 | + |
| 35 | +### Error Handling |
| 36 | + |
| 37 | +- Use descriptive error messages |
| 38 | +- Prefer custom error classes for specific error types |
| 39 | +- Handle errors appropriately |
| 40 | + |
| 41 | +## Testing |
| 42 | + |
| 43 | +- Use Jest for unit and integration tests |
| 44 | +- Name test files with `.test.ts` suffix |
| 45 | +- Group related tests with `describe` blocks |
| 46 | +- Use clear and descriptive test names with `it` statements |
| 47 | +- Use mocks for external dependencies |
| 48 | + |
| 49 | +Example: |
| 50 | +```typescript |
| 51 | +describe('MyFunction', () => { |
| 52 | + it('returns the expected result when given valid input', () => { |
| 53 | + // Arrange |
| 54 | + const input = 'valid input'; |
| 55 | + |
| 56 | + // Act |
| 57 | + const result = myFunction(input); |
| 58 | + |
| 59 | + // Assert |
| 60 | + expect(result).toBe('expected output'); |
| 61 | + }); |
| 62 | +}); |
| 63 | +``` |
| 64 | + |
| 65 | +## Code Organization |
| 66 | + |
| 67 | +- Organize code by feature or domain |
| 68 | +- Keep files focused on a single responsibility |
| 69 | +- Use barrel exports (index.ts files) sparingly, and with named exports, to simplify imports |
| 70 | +- Separate interfaces/types into their own files when they become large |
| 71 | + |
| 72 | +## Git Workflow |
| 73 | + |
| 74 | +- Create feature branches from `main` |
| 75 | +- Use descriptive commit messages |
| 76 | +- All pull requests must be linked to an open issue |
| 77 | +- Pull requests should target the `main` branch |
| 78 | + |
| 79 | +## Project Structure |
| 80 | + |
| 81 | +- `/packages`: Contains all the project packages |
| 82 | +- `/scripts`: Contains build and utility scripts |
| 83 | +- `/docs`: Project documentation |
| 84 | +- `/external`: External dependencies |
| 85 | + |
| 86 | +## Dependencies |
| 87 | + |
| 88 | +- Use Yarn as the package manager |
| 89 | +- Pin dependency versions where appropriate |
| 90 | + |
| 91 | +## Best Practices |
| 92 | + |
| 93 | +1. Follow the Single Responsibility Principle |
| 94 | +2. Write pure functions when possible |
| 95 | +3. Use async/await for asynchronous code |
| 96 | +4. Use descriptive variable names |
| 97 | +5. Keep functions small and focused |
| 98 | +6. Use TypeScript's type system to prevent bugs |
| 99 | +7. Document complex logic with comments |
| 100 | +8. Write tests for all new functionality |
0 commit comments