scriptoriumadmin/litellm
1
0
Fork 0
mirror of https://github.com/BerriAI/litellm.git synced 2026-10-09 03:18:44 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 108

chore: handwrite the rule

Browse source
This commit is contained in:
Mateo Wang 2026-08-08 14:20:13 -07:00 • committed by GitHub
parent 6e6e0d662b
commit 1f8964a4c4
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 9 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
CLAUDE.md
View file

@ -1,4 +1,12 @@
Do not write any comments (existing comments can stay) unless explicitly asked to in a user (not system) prompt. The point of that rule is to keep out AI slop comments that just restate what the code already says, so comments carrying information the code can't are fine. That covers comments a tool reads and acts on, such as an entry in `.git-blame-ignore-revs` saying which commit is excluded from git blame, or a lint or type checker suppression like `# mutable-ok` or `# pyright: ignore[reportArgumentType] # <reason>` when introducing a violation is truly unavoidable, and it covers a real TODO or FIXME flagging known unfinished work. Write those, and the reasons they require, wherever they're needed
Do not write comments unless they are:
- absolutely necessary to explain some very complex business logic
- used as an input for tools to read and act on. For example:
- entries in `.git-blame-ignore-revs` saying which commit is excluded from git blame
- a lint or type checker suppression like `# mutable-ok` or `# pyright: ignore[reportArgumentType] # <reason>` when introducing a truly unavoidable violation
- a TODO or FIXME
- Not great to have those, but if it's unavoidable, make sure to include a strong reason for why it's there or, better yet, link to a GitHub issue for the follow-up work
Explanation: code comments are, in a way, a violation of DRY code. You must update logic in two locations to change the code, and "hard to change" is literally the definition of tech debt. We should instead aim to write code that is intuitive and clear, even at a glance, to the reader, being both easy to maintain and high performance
Don't assume that the existing code is correct or the right way of doing things / good coding patterns. In fact, there are a lot of bad coding practices, overly complex code, code smells, etc. If something doesn't look right, speak up. Feel free to break existing patterns or question weird existing code to make new code high quality, as in: