From 67880a93cd3be9d33ad443825b293aac33e22b8e Mon Sep 17 00:00:00 2001 From: anovoa Date: Sat, 5 Apr 2025 21:10:36 +0200 Subject: [PATCH] =?UTF-8?q?Feature=20-=20main=20-=20A=C3=B1adir=20instrucc?= =?UTF-8?q?iones=20para=20la=20generaci=C3=B3n=20de=20c=C3=B3digo=20y=20re?= =?UTF-8?q?visi=C3=B3n?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .github/copilot-instructions.md | 68 +++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 .github/copilot-instructions.md diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 0000000..adf32d5 --- /dev/null +++ b/.github/copilot-instructions.md @@ -0,0 +1,68 @@ +# Instructions for Copilot +## Code Generation +- All code must be written in **English**. +- Explicitly declare **access modifiers** for procedures (`local`, `internal`, `public`), prioritizing `local` or `internal` as appropriate. +- When using `Insert`, `Modify`, `Delete` or `DeleteAll`, always pass `true` as a parameter to ensure full execution of business logic. Example: `Insert(true)`, `Modify(true)`. +- When using `FindSet()`, specify the parameter according to the block’s intent. If the table will be modified, use `FindSet(true)`; otherwise, use `FindSet(false)`. +- When assigning a value to a field, **do not assign it directly**; use `Validate` to ensure the correct execution of related logic. +- Do not hardcode **text** in messages or user interaction elements. Use `Labels` to facilitate translation file generation. +- Do not declare multiple variables of the same type in a single line. Incorrect example: `MyInt1, MyInt2, MyInt3: Integer;`. +- Control all graphical interface elements (`Message`, `Confirm`, etc.) using `GuiAllowed()` to prevent errors in background processes. +- Use the correct suffix in `Label`-type variables according to their purpose: + - `Msg` – Messages. + - `Tok` – Constants such as tokens, URLs, etc. + - `Err` – Errors. + - `Qst` – For `StrMenu` or `Confirm`. + - `Lbl` – Texts that require translation (`Label`, `Caption`). +- Apply **SOLID** principles in code design: + - **SRP** – Single Responsibility Principle: Each module should have only one reason to change. + - **OCP** – Open/Closed Principle: Code should be open for extension (events, interfaces) but closed for direct modification. + - **LSP** – Liskov Substitution Principle: Use interfaces to ensure implementations can be interchanged without altering expected behavior. + - **ISP** – Interface Segregation Principle: Split large interfaces into several smaller, more specific ones. + - **DIP** – Dependency Inversion Principle: Modules should depend on abstractions (interfaces, events), not on concrete implementations. +- Do not use `Find(-)`, `Find(+)`, `Find(=)`, etc. Use `FindFirst()`, `FindLast()` or `FindSet()` instead. +- Always use the most appropriate data type: `primitive types`, `List`, `Dictionary`, `JsonObject`, `TextBuilder`, among others. +- All objects and procedures must be properly documented using **XML comments**. +- Do not use `//` or `/* */` comments; all documentation must be provided through XML blocks above procedures and objects. +- Avoid adding redundant or unhelpful comments. +- When adding elements to pages, prioritize `AddFirst` or `AddLast` over `AddAfter` or `AddBefore`. +- Ensure **referential integrity** when linking fields. +- In event subscriptions, explicitly configure: `SkipOnMissingLicense = false` and `SkipOnMissingPermission = false`. +- Remove unnecessary lines such as redundant calls to `Reset` or default initializations for newly created variables. +- When a variable refers to an object, use the exact **same name** as the object, with no spaces, quotes, or special characters. +- Consider the **cyclomatic complexity** of the code. +- Simplify control structures and avoid unnecessary `begin/end` blocks. +- If a function has more than six parameters, consider using structures like `Dictionary`, `Record`, or others to simplify the call. +- Always declare the **exact length** for `Text` or `Code` type fields and variables. +- If adding `FlowField` type fields in a table, make sure to set `Editable = false`. +- Use **PascalCase** for naming objects, functions, and variables. +- Do not use `Option`; create an `Enum` type instead. +- When subscribing to an event that receives a table as a parameter, first check if it is **temporary**. If it is, use `exit;`. +- Do not include code directly within **triggers**; create separate functions that can be called from the trigger. +- In new tables, add the `DataClassification` property **only at the table level**, **never on individual fields**. +- In table extensions, **do not add `DataClassification` at the table level**; this will cause an error. Add it only to specific fields. +- Avoid **hardcoding** object IDs. Use the **object name** instead. +- Structure the code according to its purpose. Prioritize in the following order: + - Use **codeunits** for general and reusable logic. + - Use **tables** for logic related to entities. + - Use **pages** exclusively for user interaction. +- All variable names must be **clear and descriptive**. Avoid meaningless abbreviations or single letters. +- When creating a table, define the `DrillDownPageId` and `LookupPageId` properties, referencing the corresponding list-type page. +- Use the condition directly in validations. Avoid constructs like `if Condition = true` or `= false`. + +## Code Review +- Verify that all added procedures are documented with XML blocks. +- Ensure the code complies with all established generation instructions. +- Make code review comments in English and respectfully insulting the developer in Spanish as a loving reminder that they can do better. + +## Commit Message Generation +- The message must be written in English. +- Use the following format: + `[Type] - [Branch Name] - [Brief Description]` + Example: `Bug - EV001 - Optimización del cálculo de impuestos` +- Include a clear, precise, and concise description of the changes made. + +## Pull Request Title and Description Generation Instructions +- Titles: Use a clear format that includes the main purpose of the changes. + Example: `Fix: Error in discount calculation logic` +- Descriptions: Include an overview of the changes made, explaining their impact and purpose.