wolves/leetcode
1
0
Fork 0
mirror of https://github.com/lWolvesl/leetcode.git synced 2026-01-12 18:08:38 +08:00
Code Issues Packages Projects Releases Wiki Activity

Add repository guidelines (AGENTS.md)

Browse Source
This commit is contained in:
wolves
2025-11-24 14:38:48 +08:00
parent a1094d0d17
commit 160a668b19
1 changed files with 18 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
AGENTS.md Normal file
View File

@@ -0,0 +1,18 @@
# Repository Guidelines
## Project Structure & Module Organization
Daily challenge archives (`23/04`, `24`, `25`) mirror the YYYY/MM problem drops from LeetCode; each subdirectory holds the source for a single prompt. Topic-driven folders (`dataStruct`, `dynamic planning`, `greed`, `else`, `key`, `we`) group reusable headers (`*.h`), Go entry points, and the occasional Python prototype. Shared helpers such as `tools/map.h` plus scratch runners (`main.c`, `main.go`) live in the repo root. Reproducible experiments sit in `test/`, alongside small driver programs (`test/test1.c`, `test/file.c`) and fixture files (`test/example.txt`). Place new assets beside the closest-matching module and keep helper code centralized in `tools/` so every language target can include it via `#include "tools/map.h"`.
## Build, Test, and Development Commands
- `gcc main.c -I greed -I dataStruct -I tools -std=c17 -Wall -Wextra -O2 -o .build/main.exe`: compile a local driver that stitches headers together; point the include path at whichever topic folder contains the solution under test.
- `clang++ 25\\11\\solution.cpp -I tools -std=c++20 -Wall -Wextra -O2 -o .build/2511.exe && .\\.build\\2511.exe < test\\example.txt`: run C++ implementations that live in the dated folders with sample input.
- `go run main.go`: execute Go stubs or quick playgrounds when validating algorithm ideas.
## Coding Style & Naming Conventions
C/C++ code uses 4-space indents, brace-on-same-line, and camelCase for functions that mirror LeetCode signatures (`largestNumber`, `maxProfit`). Keep headers self-contained; include `<stdlib.h>`, `<string.h>`, etc. directly. Prefer descriptive file names that equal the problem id (`greed/179.h`, `dataStruct/409.h`). Python helpers should follow snake_case and stay under 80 columns to match the existing scripts (`greed/11.py`, `lcs01.py`).
## Testing Guidelines
Driver files inside `test/` document how to wire solutions into simple harnesses. When adding a solution, drop a focused test driver (e.g., `test/179_largestNumber.c`) and feed it sample cases through redirected stdin (`.\\build\\179.exe < test\\example.txt`). Keep assertions explicit so reviewers can trace failing inputs quickly.
## Commit & Pull Request Guidelines
Recent commits use numeric messages (`717`, `251116`) that track the corresponding LeetCode id or date. Continue that convention: `<problem-id>[-optional-note]` keeps history scannable. Pull requests should mention the problem link, describe the approach/complexity, list any new tests, and attach screenshots only when visual assets change. Reference related issues or discussions to make triage easy.