Agent instructions

[tameware]

1. Use snake_case for C and C++ code.
2. Follow TTD.

[Copilot]

Pull request overview

Adds an AGENTS.md document to guide contributors/agents on naming and test-driven development expectations for DDS changes.

Changes:

• Introduces naming guidance for C/C++ identifiers (favoring snake_case, with exceptions for legacy/public APIs).
• Documents a strict red-green-refactor TDD workflow and test structuring expectations (AAA, edge cases).

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

AGENTS.md:3

• The naming guidance here is incomplete compared to the repo’s established C++ naming rules (e.g., constants use PascalCase and macros use ALL_CAPS). Since this file is meant to guide agents/contributors, it should either include those rules or explicitly defer to .github/instructions/cpp.instructions.md to avoid inconsistent naming for new code.

For C and C++ code, use snake_case for functions, methods, variables, and parameters. For C++ types use PascalCase, and for member variables use snake_case with a trailing underscore.

[zzcgumn]

I have started work to create a set of specifications to help coding agents. I suggest we add a project AGENTS.md file either as part of this upcoming pull request or in a later one. Our .github/copilot-instructions.md file does also need to be updated.

[tameware]

I forgot that this was still a draft. I've promoted it. I'll merge it now with your approval, @zzcgumn - we can add your stuff to it when you're ready. I needed this because I found that Cursor was ignoring .github/copilot-instructions.md.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[zzcgumn]

I like using test driven development with coding agents but it is not a silver bullet. Maybe add something like this?

Apply these instructions when test driven development has been requested. Always ask if it is unclear whether TDD should be used.

[tameware]

@zzcgumn > Maybe add something like this?

I've had good results using TDD always. I learned about it in 2000. My code after that was more robust and easier to follow, but only when I remembered to use it! In college in the early '80s we'd been taught that our code should have strong cohesion and weak coupling, but not how to achieve that. It seemed an art. TDD is a tool that almost forces it.

That said, I did have to add the line that says it should not apply to documentation!

[tameware]

Kent Beck noted that TDD helps maximize the amount of code not written. This should be useful when we deal with AIs, since they love writing voluminous code.

[zzcgumn]

I am happy for TDD to be the default mode we ask agents to work with. Beck's point is very interesting as they tend to write lot of code, repeat themselves and write comments that explain what is obvious.

[zzcgumn]

Couple of things to discuss about this. I had failed to appreciate that you cannot point Cursor to the .github directory for instructions in any other way.

[zzcgumn]

We can return to the TDD discussion later. I suppose one advantage is that we try to force all contributors to write well-tested code.