- Don't output unnecessary explanations or comments unless specifically requested or really mandatory.
- DRY (Don't Repeat Yourself): Avoid code duplication by reusing existing functions and modules.
- Clean Code: If you need comments, it indicates that the code may need refactoring for clarity and should be extracted into well-named functions or modules.
- Consistent Naming Conventions: Use clear and consistent naming conventions for variables, functions, and modules.
- Error Handling: Implement robust error handling to manage potential issues gracefully.
- Use Error Codes for all Errors (COMPONENTNAME-FUNCTION-CURRENTSTEP) e.g.: SMREPO-UPDPROP-EXECDBQUERY
- Code Readability: Ensure the code is easy to read and understand, with proper indentation and spacing
- Ensure that the Cognitive Complexity of functions does not exceed 15. Refactor complex functions into smaller, manageable pieces.
- MANDATORY: Use GOQU for SQL Queries in go. No Plain Text.
- Try to implement scalable and performant code - no prototyping.
- Check if you understood the task requirements.
- Ask Questions if any part of the task is unclear.
- Create a ToDo List
- Collect Context around semantically near files/methods/functions
- Implement Test Cases in integration_tests if applicable
- Modify the Codebase
- Run Tests and Ensure All Pass
- Perform Code Review and Refactoring
- Perform Post-Task Steps
- Use basyxschema.sql for reference when modifying database-related code.
- Ensure that any changes to the database schema are reflected in the basyxschema.sql file.
- When modifying code, consider the impact on related modules and ensure that changes are consistent across the codebase.
- Always run integration tests after making changes to ensure that the modifications do not break existing functionality. Important: Clean Testcache before running tests to avoid false positives/negatives.
- Run linter and formatter on the modified files to ensure code quality and consistency.
- Also fix linting errors of unrelated files if you encounter them while running the linter.
- Do a Self-Code Review to ensure that the changes meet the task requirements and adhere to coding standards. (CC, DRY)
- go test -v ./internal/submodelrepository/integration_tests
- NEVER USE ADDITIONAL FLAGS (e.g. -run) UNLESS SPECIFICALLY REQUESTED IN THE TASK. ALL TESTS MUST BE RUN TO ENSURE CODE QUALITY AND INTEGRITY.