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
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,8 +4,19 @@ For reviewing PRs:
4
4
* Use meaningful variable names, e.g. `measurement` not `msm`, avoid abbreviations.
5
5
* Flag overly complex or long/functions: break up in smaller functions
6
6
* On Windows it is necessary to explicitly export all functions from the library which should be externally accessible. To do this, include the macro `GTSAM_EXPORT` in your class or function definition.
7
+
* When adding or modifying public classes/methods, always review and follow `Using-GTSAM-EXPORT.md` before finalizing changes, including template specialization/export rules.
7
8
* If we add a C++ function to a `.i` file to expose it to the wrapper, we must ensure that the parameter names match exactly between the declaration in the header file and the declaration in the `.i`. Similarly, if we change any parameter names in a wrapped function in a header file, or change any parameter names in a `.i` file, we must change the corresponding function in the other file to reflect those changes.
9
+
* For templated classes/factors in wrappers, prefer the normal `.i` template mechanism over hand-writing one wrapper class per instantiation. Let the wrapper generate names such as `AttitudeFactorRot3` from `template<...> class AttitudeFactor`.
10
+
* Do not add or keep C++ `using`/`typedef` aliases solely to manufacture wrapper names. Only keep aliases when they are genuinely useful in the C++ API as well.
8
11
* Classes are Uppercase, methods and functions lowerMixedCase.
9
12
* Public fields in structs keep plain names (no trailing underscore).
10
13
* Apart from those naming conventions, we adopt Google C++ style.
14
+
* Prefer concise, elegant examples: use the fewest helpers possible, favor direct construction and small local functors/lambdas over extra adapter functions.
15
+
* Notebooks in `*/doc/*.ipynb` and `*/examples/*.ipynb` should follow the standard preamble:
16
+
1) title/introduction markdown cell,
17
+
2) copyright markdown cell tagged `remove-cell`,
18
+
3) Colab badge markdown cell,
19
+
4) Colab install code cell tagged `remove-cell`,
20
+
5) imports/setup code cell.
21
+
Use the same `remove-cell` tagging convention as existing notebooks so docs build and Colab behavior stay consistent.
11
22
* After any code change, always run relevant tests via `make -j6 testXXX.run` in the build folder $WORKSPACE/build. If in VS code, ask for escalated permissions if needed.
0 commit comments