Development Guidelines

This section contains documentation for developers contributing to the Digibit ERP system, including coding standards, best practices, and development workflows.

Table of Contents

Code Standards

TypeScript/JavaScript

  • Follow the official Angular style guide
  • Use consistent naming conventions (PascalCase for classes, camelCase for methods/variables)
  • Maintain a maximum line length of 120 characters
  • Use meaningful variable and function names
  • Implement proper error handling
  • Use TypeScript interfaces for object structures
  • Leverage RxJS observables for reactive programming

HTML Templates

  • Use semantic HTML elements where appropriate
  • Keep templates clean and readable
  • Use property binding and event binding consistently
  • Implement accessibility attributes (aria-* labels, alt text)
  • Follow BEM methodology for CSS class naming

SCSS/CSS

  • Organize styles in a modular way
  • Use variables for colors, spacing, and typography
  • Follow a consistent naming convention
  • Keep specificity low
  • Use responsive design principles

Development Workflow

Branch Strategy

  • Use feature branches for new functionality
  • Name branches descriptively (e.g., feature/user-authentication, bugfix/login-error)
  • Keep branches focused on a single issue or feature
  • Regularly rebase from the main branch to stay up-to-date

Local Development

  1. Create a new branch from main: git checkout -b feature/my-feature
  2. Make changes following coding standards
  3. Write or update tests as needed
  4. Commit changes with descriptive messages
  5. Push the branch: git push origin feature/my-feature
  6. Create a pull request to merge into main

Testing Practices

Unit Tests

  • Write unit tests for all services and components
  • Aim for at least 80% code coverage
  • Use Jasmine and Karma for testing
  • Test both positive and negative cases
  • Mock external dependencies appropriately

Component Tests

  • Test component inputs, outputs, and interactions
  • Verify DOM manipulation and rendering
  • Test user events and state changes
  • Use Angular Testing Library for component testing

End-to-End Tests

  • Cover critical user journeys
  • Use Cypress for e2e testing
  • Test across different browsers when possible

Documentation Standards

Code Comments

  • Use JSDoc-style comments for public methods and classes
  • Explain complex logic with inline comments
  • Keep comments up-to-date with code changes
  • Avoid redundant comments that merely repeat what code does

Inline Documentation

  • Document complex algorithms or business logic
  • Explain the "why" behind non-obvious decisions
  • Reference relevant tickets or requirements when applicable

Commit Message Guidelines

Follow the conventional commits specification:

<type>(<scope>): <short summary>

Types: - feat: New feature - fix: Bug fix - docs: Documentation changes - style: Code style changes (white-space, formatting, missing semi-colons) - refactor: Code changes that neither fix a bug nor add a feature - test: Adding or correcting tests - chore: Other changes that don't modify src or test files

Examples: - feat(auth): add password reset functionality - fix(api): resolve issue with user data retrieval - docs(readme): update installation instructions

Pull Request Process

  1. Ensure your branch is up-to-date with main
  2. Run all tests locally to ensure they pass
  3. Update documentation as needed
  4. Submit a pull request with a clear title and description
  5. Link to any relevant issues
  6. Request reviews from team members
  7. Address feedback and make necessary changes
  8. Wait for approval before merging

Code Review Checklist

Reviewers should check for: - [ ] Code follows established standards - [ ] Tests are included and passing - [ ] Documentation is updated - [ ] Code is clean and well-structured - [ ] Security considerations are addressed - [ ] Performance implications are considered - [ ] Accessibility requirements are met - [ ] Changes align with project architecture - [ ] No hard-coded values where configuration should be used - [ ] Proper error handling is implemented

Additional Resources