You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+17-1Lines changed: 17 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -69,21 +69,37 @@ Keep the docs focused on `CrestApps.Core`. If you need to mention the Orchard Co
69
69
- After the last null-check/argument-validation line in a method, add a blank line before the next statement
70
70
- If a method has only one null-check/argument-validation line, still add a blank line after that final guard line
71
71
- Add a blank line before a `return` statement unless the `return` is the first statement inside a `{ ... }` block
72
+
- Never use more than one consecutive blank line
72
73
- Add a blank line before and after `if` blocks, `switch` statements, and loops unless the block is immediately preceded by `{`
73
74
- Do not add a blank line between an `if`/`else`/`switch`/loop condition and its opening `{`
75
+
- Do not add a blank line immediately after `#pragma warning disable` or immediately before `#pragma warning restore`
76
+
- Do not add a blank line immediately after `#pragma warning restore` when the next line is `{`
77
+
- Add a blank line before a `#pragma warning disable` block when it starts a new member after a closing `}`
78
+
- Add a blank line between a `#pragma warning restore` and the next `#pragma warning disable` when they guard separate members
79
+
- Format conditional operators across multiple lines with the condition on its own line and the `?` and `:` tokens on their own indented lines
74
80
- Use `var` consistently with repository style
75
81
- Do not use `global using` files; add explicit `using` directives at the top of each file instead.
76
82
- Prefer top-of-file `using` directives over fully qualified type names in code.
77
83
- Only use expression-bodied members when the entire member fits on a single short line; use a full block body for anything longer or split across lines
- Keep public docs and comments honest to the current code.
80
-
- Always document new interfaces, their methods and arguments along with documenting every property on domain models using `<summary>` block.
86
+
- Always document every method, including constructor overloads, with accurate XML `<summary>` and `<param>` blocks for every argument.
87
+
- Only add XML `<param>` tags for parameters that actually exist on the documented member, and keep them in the exact same order as the signature.
88
+
- Always document publicly accessible properties with accurate XML `<summary>` blocks.
89
+
- Always insert a blank line before XML `<summary>` documentation blocks unless they are immediately preceded by `{`.
90
+
- Never insert a blank line between an XML documentation block and the member it documents.
91
+
- If XML documentation already exists, improve the existing block in place instead of stacking a second `<summary>` block above it.
92
+
- Always document new interfaces and all of their members and arguments.
93
+
- When a constructor has more than one parameter, span its parameter list across multiple lines.
94
+
- Put constructor initializer clauses like `: base(...)` on their own indented line
95
+
- Seal publicly accessible classes by default and only leave them unsealed when inheritance is intentionally required.
81
96
- Always treat warnings are errors in the solutions and ensure every warning is addressed.
82
97
- Always learn from my prompts, preference and styles and update the `copilot-instructions.md` file with any new preferences that I share in the future.
83
98
- Prefer SOLID and DRY refactors that consolidate duplicated provider, transport, or store logic into shared abstractions before adding new one-off implementations.
84
99
- Favor additive shared infrastructure first, then migrate consumers in behavior-safe steps when a full replacement is too risky for a single change.
85
100
- When working in framework code meant for external adoption, optimize for consistency and long-term maintainability across providers and hosts, not just local fixes.
86
101
- For optional provider integrations in sample hosts, do not eagerly read validated options in UI setup paths when an unconfigured provider should simply appear unavailable rather than crash the page.
102
+
- Always keep exactly one trailing newline at the end of each file, no more and no less.
<!--- Please make sure that you're familiar with our contribution guidelines before submitting a pull request: https://docs.orchardcore.net/en/latest/guides/contributing/. -->
1
+
<!--- Please make sure that you're familiar with our contribution guidelines before submitting a pull request: https://docs.orchardcore.net/en/latest/guides/contributing/. -->
0 commit comments