Skip to content

Commit 2a0a45e

Browse files
committed
Merge branch 'main' into dev/plugin_client_updates
2 parents 91bd900 + 2ae4d72 commit 2a0a45e

18 files changed

Lines changed: 2538 additions & 436 deletions

File tree

AGENTS.md

Lines changed: 73 additions & 160 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,42 @@ This document provides directive guidelines for AI assistants working on the YUP
1616

1717
**NEVER EVER run bash commands to configure, compile or test the implementation, acknowledge that we should test and we'll run and report any issue.**
1818

19+
## AI Decision Making Rules
20+
21+
### Always:
22+
1. **Rely on the C++20 language and standard library** so use it (unless the feature is not supported in all YUP's platforms)
23+
2. **Check existing patterns** in similar modules first
24+
3. **Use YUP conventions** for similar functionality
25+
4. **Use YUP infrastructure** instead of reinventing the wheel
26+
5. **If the same functionality can be provided with less code and complexity** prefer less code
27+
6. **Always prefer reusing code than creating duplicated code**
28+
7. **Prefer composition over inheritance**
29+
8. **Make classes small and focused** (single responsibility)
30+
9. **Use const-correctness** throughout
31+
10. **Do not leak internal details**
32+
11. **Follow the open-closed principle**
33+
12. **Never assume we use plain JUCE7 functionality, always check APIs** as they might have evolved
34+
35+
### When implementing new features:
36+
1. **Always provide extensive and useful doxygen documentation** for public APIs
37+
2. **Make sure new code is always tested**
38+
39+
### When writing tests:
40+
1. **Test primarily public interfaces only**
41+
2. **Cover normal, edge, and error cases**
42+
3. **Use descriptive test names** (e.g., `ReturnsNullForInvalidInput`)
43+
4. **Group related tests** in test fixtures
44+
5. **Keep tests independent** and deterministic
45+
6. **Never Use C or C++ macros (like M_PI)** use yup alternatives
46+
47+
### When suggesting refactoring:
48+
1. **Maintain existing API contracts**
49+
2. **Follow established module patterns**
50+
3. **Preserve platform-specific code organization**
51+
4. **Update tests accordingly**
52+
5. **Consider performance implications**
53+
6. **Keep API usage simple and effective**
54+
1955
### 1. File Headers
2056
**ALWAYS** start new files with this exact header:
2157

@@ -71,44 +107,6 @@ For main module headers (e.g., `yup_graphics.h`), include this declaration block
71107
Refer to `./docs/YUP Module Format.md` for more info if needed.
72108

73109
### 3. Formatting Rules (Allman Style)
74-
```cpp
75-
// Classes
76-
class MyClass
77-
{
78-
public:
79-
MyClass();
80-
~MyClass();
81-
82-
private:
83-
int memberVariable;
84-
};
85-
86-
// Functions
87-
void functionName()
88-
{
89-
// implementation
90-
}
91-
92-
// Control structures
93-
if (condition)
94-
{
95-
// code
96-
}
97-
else
98-
{
99-
// code
100-
}
101-
102-
for (int i = 0; i < count; ++i)
103-
{
104-
// code
105-
}
106-
107-
while (condition)
108-
{
109-
// code
110-
}
111-
```
112110

113111
### 4. Naming Conventions
114112
- **Classes:** `PascalCase` (e.g., `GraphicsContext`)
@@ -125,32 +123,30 @@ while (condition)
125123
// 1. Own module header (if in .cpp file)
126124
#include <yup_graphics/yup_graphics.h>
127125

128-
// 2. Standard library
129-
#include <memory>
130-
#include <vector>
131-
132-
// 3. External libraries (Rive, etc.)
133-
#include <rive/rive.h>
134-
135-
// 4. Other project modules
126+
// 2. Other project modules
136127
#include "yup_core/yup_core.h"
137128

138-
// 5. Same module headers
129+
// 3. Same module headers
139130
#include "graphics/yup_Color.h"
140131
#include "primitives/yup_Point.h"
132+
133+
// 5. External libraries (Rive, etc.)
134+
#include <rive/rive.h>
135+
136+
// 4. Standard library
137+
#include <memory>
138+
#include <vector>
141139
```
142140

143141
### 6. Namespace Usage
144142
```cpp
145-
// NEVER use "using namespace"
146-
// In test files: OK for widely used namespaces
143+
// NEVER use "using namespace" except in test files
147144
using namespace yup;
148145

149146
// Prefer limited scope usage
150147
TEST (MyClassTests, someFunction)
151148
{
152149
using namespace std::chrono;
153-
// use chrono types without std::chrono:: prefix
154150
}
155151
```
156152
@@ -166,8 +162,13 @@ modules/yup_module_name/
166162
│ ├── yup_ClassName.h
167163
│ └── yup_ClassName.cpp
168164
└── native/ // Platform-specific code
169-
├── yup_ClassName_win32.cpp
165+
├── yup_ClassName_android.cpp
166+
├── yup_ClassName_windows.cpp
170167
├── yup_ClassName_linux.cpp
168+
├── yup_ClassName_wasm.cpp
169+
├── yup_ClassName_emscripten.cpp
170+
├── yup_ClassName_mac.mm
171+
├── yup_ClassName_ios.mm
171172
└── yup_ClassName_apple.mm
172173
```
173174
Avoid going deeply nested into modules. Prefer a single subdirectory whenever possible for YUP modules (might be ok for thirdparties as we don't control the upstream structure).
@@ -183,33 +184,6 @@ tests/module_name/
183184
184185
## Class Design Templates
185186
186-
### Basic Class Template
187-
```cpp
188-
class ClassName
189-
{
190-
public:
191-
ClassName();
192-
~ClassName();
193-
194-
// Copy/move constructors if needed
195-
ClassName (const ClassName& other) = delete;
196-
ClassName& operator= (const ClassName& other) = delete;
197-
198-
// Public interface
199-
void doSomething (int arg);
200-
int getValue() const;
201-
bool isValid() const;
202-
203-
private:
204-
// Member variables
205-
int value;
206-
bool initialized;
207-
208-
// Helper methods
209-
void initialize();
210-
};
211-
```
212-
213187
### YUP-Style Class (with leak detector)
214188
```cpp
215189
class YupStyleClass
@@ -221,6 +195,8 @@ public:
221195
void publicMethod();
222196
223197
private:
198+
void privateMethod();
199+
224200
int memberVar;
225201
226202
YUP_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (YupStyleClass)
@@ -239,15 +215,17 @@ using namespace yup;
239215

240216
namespace
241217
{
242-
// Test helpers and constants
243-
constexpr int kTestValue = 42;
244218

245-
class TestHelper
246-
{
247-
public:
248-
static void setupTestData() { /* ... */ }
249-
};
250-
}
219+
// Test helpers and constants, prefer move them into fixtures so they don't clash in unity builds
220+
constexpr int kTestValue = 42;
221+
222+
class TestHelper
223+
{
224+
public:
225+
static void setupTestData() { /* ... */ }
226+
};
227+
228+
} // namespace
251229

252230
class ClassNameTests : public ::testing::Test
253231
{
@@ -279,54 +257,17 @@ TEST (ClassNameTests, StaticMethodBehavesCorrectly)
279257
}
280258
```
281259
282-
## AI Decision Making Rules
283-
284-
### Always:
285-
1. **Rely on the C++20 language and standard library** so use it (unless the feature is not supported in all YUP's platforms)
286-
2. **Check existing patterns** in similar modules first
287-
3. **Use YUP conventions** for similar functionality
288-
4. **Use YUP infrastructure** instead of reinventing the wheel
289-
5. **Prefer composition over inheritance**
290-
6. **Make classes small and focused** (single responsibility)
291-
6. **Use const-correctness** throughout
292-
7. **Do not leak internal details**
293-
8. **Follow the open-closed principle**
294-
9. **Never assume we use plain JUCE7 functionality, always check APIs** as they might have evolved
295-
296-
### When implementing new features:
297-
1. **Always provide extensive and useful doxygen documentation** for public APIs
298-
2. **Make sure new code is always tested**
299-
300-
### When writing tests:
301-
1. **Test primarily public interfaces only**
302-
2. **Cover normal, edge, and error cases**
303-
3. **Use descriptive test names** (e.g., `ReturnsNullForInvalidInput`)
304-
4. **Group related tests** in test fixtures
305-
5. **Keep tests independent** and deterministic
306-
6. **Never Use C or C++ macros (like M_PI)** use yup alternatives
307-
308-
### When suggesting refactoring:
309-
1. **Maintain existing API contracts**
310-
2. **Follow established module patterns**
311-
3. **Preserve platform-specific code organization**
312-
4. **Update tests accordingly**
313-
5. **Consider performance implications**
314-
6. **Keep API usage simple and effective**
315-
316260
### Platform-specific code:
317261
```cpp
318-
#if YUP_WINDOWS
319-
// Windows implementation
320-
#elif YUP_MAC
321-
// macOS implementation
322-
#elif YUP_IOS
323-
// iOS implementation
324-
#elif YUP_LINUX
325-
// Linux implementation
326-
#elif YUP_ANDROID
327-
// Android implementation
328-
#elif YUP_WASM
329-
// WebAssembly implementation
262+
#if YUP_WINDOWS // Windows
263+
#elif YUP_MAC // macOS
264+
#elif YUP_IOS // iOS
265+
#elif YUP_LINUX // Linux
266+
#elif YUP_ANDROID // Android
267+
#elif YUP_WASM // WebAssembly (including emscripten)
268+
#elif YUP_EMSCRIPTEN // WebAssembly (only emscripten)
269+
#elif YUP_DESKTOP // Windows/macOS/Linux
270+
#elif YUP_MOBILE // Android/iOS
330271
#endif
331272
```
332273

@@ -375,34 +316,6 @@ Before suggesting code, verify:
375316
- [ ] Thread safety considerations if applicable
376317
- [ ] Documentation for public APIs
377318
378-
## Common Patterns to Follow
379-
380-
### Resource Management
381-
```cpp
382-
// Prefer RAII and smart pointers
383-
class ResourceManager
384-
{
385-
private:
386-
std::unique_ptr<Resource> resource;
387-
std::vector<std::shared_ptr<Item>> items;
388-
};
389-
```
390-
391-
### Optional Values
392-
```cpp
393-
// Use yup::var for dynamic types
394-
// Use std::optional for optional values
395-
std::optional<int> findValue (const String& key);
396-
```
397-
398-
### String Handling
399-
```cpp
400-
// Use yup::String for most string operations
401-
void processText (const yup::String& text);
402-
403-
// Use std::string only when interfacing with non-YUP code
404-
```
405-
406319
## Differences with JUCE
407320
408321
- We use American english in YUP, so it's `center` and not `centred`, or `Color` and not `Colour`

0 commit comments

Comments
 (0)