GitHub Copilot Instructions

GitHub Copilot Instructions¶

ESLint Guidelines¶

• Follow the coding standards defined in .eslintrc.json.
• Use single quotes for strings.
• Always include semicolons at the end of statements.
• Prefer const and let over var.
• Use arrow functions where appropriate.
• Ensure proper indentation (2 spaces).
• Avoid unused variables and imports.
• Use strict equality (=== and !==).
• Prefer destructuring assignments for objects and arrays.
• Do not use console statements in production code.
• Follow the project's import order and grouping conventions.

Fundamental Programming Principles¶

• Keep It Simple, Stupid (KISS): Strive for simplicity in design and implementation; avoid unnecessary complexity.
• Don't Repeat Yourself (DRY): Reuse code and abstractions to minimize duplication.
• You Aren't Gonna Need It (YAGNI): Only implement features and logic that are currently required.
• Separation of Concerns: Organize code so that each module or function has a single, well-defined responsibility.
• Fail Fast: Validate inputs and handle errors early to prevent cascading failures.
• Write Self-Documenting Code: Use clear naming and structure so code is understandable without excessive comments.
• Prefer Composition Over Inheritance: Favor combining simple components over deep inheritance hierarchies.

General Instructions¶

• Write clean, readable, and maintainable code.
• Add comments for complex logic.

Additional Project-Specific Guidelines¶

• Use TypeScript for all new files and features.
• Define explicit types for function parameters and return values when possible.
• Prefer interfaces over type aliases for object shapes.
• Use named exports instead of default exports.
• Organize imports in the following order: external libraries, internal modules, styles, types when possible.
• Group related functions and types together in the same file when possible.
• Use Angular components and services for UI development.
• Avoid direct DOM manipulation; use Angular templates and ViewChild when necessary.
• Write unit tests for all new features and maintain high test coverage.
• Document public APIs and exported functions with JSDoc comments.
• Avoid installing unnecessary dependencies; prefer built-in or existing libraries.

Naming Conventions (Angular Best Practices)¶

• Use descriptive and meaningful names for all identifiers.
• Component, service, and directive class names should use PascalCase and end with their type (e.g., UserProfileComponent, AuthService, HighlightDirective).
• File names should use kebab-case and reflect the class type (e.g., user-profile.component.ts, auth.service.ts).
• Variables and function names should use camelCase.
• Interfaces should use PascalCase and start with I (e.g., IUser, IAuthResponse).
• Enum names should use PascalCase.
• Constants should use uppercase letters with underscores (e.g., MAX_RETRIES).
• Selectors for components and directives should use a unique prefix (e.g., eris-user-profile).
• Avoid abbreviations unless they are well-known and improve clarity.
• Use singular names for services and models, plural for collections.
• Prefix private properties and methods with an underscore only if required for clarity.

Guidelines for Aligning with Anticipated New Angular Versions¶

• Regularly review Angular release notes and migration guides to stay informed about upcoming changes and deprecations.
• Prefer using Angular's recommended APIs and patterns to ensure forward compatibility.
• Avoid reliance on deprecated features; refactor code proactively when deprecation warnings appear.
• Monitor third-party dependencies for Angular compatibility and update them as needed.
• Document custom workarounds or polyfills that may need revision in future Angular versions.
• Schedule regular codebase reviews to identify areas that may be impacted by upcoming Angular changes.

Sensitive Data Handling Guidelines¶

• Never commit sensitive data (such as passwords, API keys, secrets, private certificates, or personally identifiable information) to source control.
• Use environment variables or secure vaults to manage secrets and sensitive configuration values.
• If sensitive data is accidentally committed, remove it immediately and replace (rotate) the affected credentials.
• Add common sensitive files and patterns (e.g., .env, *.pem, *.key, secrets.*) to .gitignore to prevent accidental commits.
• Review all code changes for accidental inclusion of sensitive information before pushing to remote repositories.
• Use automated tools to scan for secrets in code and configuration files.
• Limit access to sensitive data in development environments and ensure production secrets are never exposed in logs or error messages.
• Document procedures for handling and reporting incidents involving sensitive data exposure.