mirror of
https://github.com/BillyOutlast/posthog.git
synced 2026-02-04 03:01:23 +01:00
chore: try and get fewer comments out of claude (#37407)
This commit is contained in:
@@ -27,11 +27,8 @@
|
||||
- CSS: Use tailwind utility classes instead of inline styles
|
||||
- Error handling: Prefer explicit error handling with typed errors
|
||||
- Naming: Use descriptive names, camelCase for JS/TS, snake_case for Python
|
||||
- Comments: Leave comments to explain tricky areas of the code or to explain WHY something is there, but don't just leave comments everywhere, the code should be default readable
|
||||
- Comments: should not duplicate the code below, don't tell me "this finds the shortest username" tell me _why_ that is important, if it isn't important don't add a comment
|
||||
- Comments: think extra hard about each and every comment, if a comment duplicates information in the code below it should not be added
|
||||
- Comments: think extra hard about each and every comment, if a comment could be made redundant by renaming or refactoring the code, we should do that instead of adding a comment
|
||||
- Python tests: do not need doc comments, give them good names, and leave off with the comments
|
||||
- Comments: should not duplicate the code below, don't tell me "this finds the shortest username" tell me _why_ that is important, if it isn't important don't add a comment, almost never add a comment
|
||||
- Python tests: do not add doc comments
|
||||
- jest tests: when writing jest tests, prefer a single top-level describe block in a file
|
||||
- any tests: prefer to use parameterized tests, think carefully about what input and output look like so that the tests exercise the system and explain the code to the future traveller
|
||||
- Python tests: in python use the parameterized library for parameterized tests, every time you are tempted to add more than one assertion to a test consider (really carefully) if it should be a parameterized test instead
|
||||
|
||||
Reference in New Issue
Block a user