|
|
|
|
@@ -5,6 +5,10 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
|
|
|
|
|
## Interaction
|
|
|
|
|
|
|
|
|
|
* ONLY modify code or other files if explicitly asked to do so
|
|
|
|
|
* keep the tone professional, brief and to the point — brevity applies to prose and
|
|
|
|
|
preamble, not to the substance of an objection or a design rationale
|
|
|
|
|
* be critical: where there is a concrete technical reason to disagree, name it once;
|
|
|
|
|
if the user reaffirms, proceed with their call without re-litigating
|
|
|
|
|
|
|
|
|
|
## Project Overview
|
|
|
|
|
|
|
|
|
|
@@ -31,6 +35,15 @@ keep the citation accurate.
|
|
|
|
|
## Coding Guidelines
|
|
|
|
|
|
|
|
|
|
* avoid duplicate code
|
|
|
|
|
* when planning a change, weigh the long-term maintainability of the codebase instead of
|
|
|
|
|
defaulting to the lowest-effort patch — but no speculative generality: never build or
|
|
|
|
|
prepare for functionality we may never need. If the maintainable solution is much larger
|
|
|
|
|
than the request, say so and let the user decide the scope.
|
|
|
|
|
* class layout: static members first, then non-static; within each, public, then protected,
|
|
|
|
|
then private (Qt `slots:`/`signals:` are ordinary non-static access groups). Inside an
|
|
|
|
|
access group the order is: nested types, static constants, aliases, methods, fields,
|
|
|
|
|
friends. Out-of-line method definitions follow the declaration order. Applies to new
|
|
|
|
|
classes and to files being edited anyway — don't reorder existing headers just to comply.
|
|
|
|
|
* do not use the "auto" keyword, with two exceptions:
|
|
|
|
|
* **named local lambdas** — a lambda's type is unnameable, and `std::function`
|
|
|
|
|
is not an acceptable substitute in per-tick code because it adds a heap
|
|
|
|
|
|
