4 ms·
- Prefer the most straightforward way of implementation. - No defensive programming. Use try/except sparingly. Let most fatal errors propogate. - No adding extr
by jwang987 6mo ago
- Prefer the most straightforward way of implementation.
- No defensive programming. Use try/except sparingly. Let most fatal errors propogate.
- No adding extra variables if there's not a clear reason to do so. Prefer simplicity
- Use comments sparingly. Function and variable names should be self-explaining and you don't need to comment most of the times
- If duplicate code is written, consider refactoring.
- DO NOT use getattr or isinstance or defensive programming patterns
- Do not create summary doc after completing a task, unless explicitly asked
- When you are asked to review git staged code changes, give feedback as if you are a senior tech lead ensuring high standards and rank the issues found with high/medium/low. Do not edit code or run git commands that manipulate the repo.
I fought with it hard during Sonnet 4.0 times. Some harnesses are actually not needed for latest model versions but I still keep these instructions.