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: AGENTS.md
+30-1Lines changed: 30 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -76,10 +76,39 @@ for new contributors.
76
76
77
77
-**No trailing whitespace**: Ensure no extra spaces at the end of lines
78
78
-**No whitespace on blank lines**: Empty lines should contain no spaces or tabs
79
-
-**Include a blank line as EOF**: Every file should end with a newline character
79
+
-**End files with a single newline**: Each file should end with a single newline character (`\n`). This is a widely adopted convention recommended by PEP 8, Python's style guide. Many Unix-style text editors and tools expect files to end with a newline character and may not handle files without one properly.
80
80
- Follow the project's existing code style and indentation patterns
81
81
- Use consistent line endings (LF for this project)
82
82
83
+
### Type Annotations
84
+
85
+
-**Always add type annotations to all functions**: All functions must include type annotations for parameters and return values
86
+
- This applies to regular functions, test functions, class methods, and async functions
87
+
- Existing code will be updated gradually; new code must be fully typed
88
+
- Follow the existing pattern in the codebase for consistency
89
+
- Examples:
90
+
91
+
```python
92
+
defcalculate_total(items: list[int]) -> int:
93
+
"""Calculate sum of items."""
94
+
returnsum(items)
95
+
96
+
deftest_my_feature() -> None:
97
+
"""Test that my feature works correctly."""
98
+
assert my_feature() == expected_result
99
+
```
100
+
101
+
### Code Comments
102
+
103
+
-**Avoid unnecessary comments**: Write self-documenting code with clear variable names, function names, and structure
104
+
-**Only add comments when absolutely necessary**: Comments should be reserved for must-have cases such as:
105
+
- Explaining complex algorithms or non-obvious logic
106
+
- Documenting "why" decisions were made (not "what" the code does)
107
+
- Warning about edge cases or subtle bugs
108
+
- Explaining workarounds for external library issues
109
+
-**Do not add comments that simply restate what the code does**: The code itself should be clear enough
110
+
-**Prefer docstrings over comments**: Use docstrings for functions, classes, and modules to document their purpose and usage
111
+
83
112
### Testing After Code Changes
84
113
85
114
After making code changes, run the following tests within a Python virtual environment to ensure code quality:
0 commit comments