-
Notifications
You must be signed in to change notification settings - Fork 18
chore: Add CLAUDE.md to register code standards with Claude agent #183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,21 @@ | ||
| # Claude Code conventions for this repo | ||
|
|
||
| ## Python style | ||
|
|
||
| - **f-strings for all logging.** Use `_logger.info(f"...")` — never `%s` interpolation. | ||
| - **Keyword-only arguments.** Add `*` to function definitions to make all parameters keyword-only, even when there is only one parameter. | ||
| - **Unused parameters.** Prefix unused function parameters with `_` (e.g. `_old_value`, `_initiator`) and add type hints to every parameter, used or not. | ||
| - **Type hints on all function parameters and return types.** Every function signature must be fully annotated. | ||
| - **StrEnum for known string sets.** When a parameter or constant is drawn from a fixed set of strings, define a `StrEnum` for it rather than using bare string literals. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. All three added — type hints on every function parameter/return type, module-only imports (with the |
||
| - **Imports: modules only.** Import modules, not individual names — except for `from typing import ...`. Example: `import sqlalchemy` not `from sqlalchemy import text`. | ||
| - **File naming: plural or uncountable nouns.** Name Python files as plural or uncountable nouns. Example: `database_migrations.py` not `database_migrate.py`. | ||
|
|
||
| ## SQLAlchemy | ||
|
|
||
| - **Derive schema metadata from models.** Never hardcode table names, column names, or column types as strings. Reference them from the SQLAlchemy model (e.g. `Model.__table__.c.column_name`) and compile types with `col.type.compile(dialect=engine.dialect)`. | ||
| - **Single transaction per logical operation.** Wrap all related DDL or DML mutations in one `with engine.connect() as conn` / `conn.commit()` block. | ||
| - **Log migrations and catch errors.** Every migration step (ALTER TABLE, backfill, index creation) should log before it runs, catch exceptions, log them, and handle `OperationalError` for concurrent deployments gracefully. | ||
|
|
||
| ## Data safety | ||
|
|
||
| - **Never delete or overwrite data files without explicit confirmation.** Use `sqlite://` (in-memory) or a `tempfile` for smoke tests and migration verification — never reference or delete files under `data/`. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I'm not sure we [should] do that. Parameter names should not be changed (breaking change) and when creating a function, there should not be any unused parameters. The only case where there can be some unused parameters is when implementing and interface. But in that case the parameter names must match the interface.
There are couple of places where I've used underscored parameters to mean private/internal, although this is not ideal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will remove this line. It stemmed from an interface implementation I'm pretty sure but I don't remember exactly anymore.