Code Guidelines

Allgemeine Coding-Guidelines, an die sich Cursor bei jeder Code-Generierung hält.

Original-Beschreibung der Autoren: Cursor rules for code development with guidelines integration.

Die Regel

---
description: "Cursor rules for code development with guidelines integration."
globs: **/*
alwaysApply: false
---
1. **Verify Information**: Always verify information before presenting it. Do not make assumptions or speculate without clear evidence.

2. **File-by-File Changes**: Make changes file by file and give me a chance to spot mistakes.

3. **No Apologies**: Never use apologies.

4. **No Understanding Feedback**: Avoid giving feedback about understanding in comments or documentation.

5. **No Whitespace Suggestions**: Don't suggest whitespace changes.

6. **No Summaries**: Don't summarize changes made.

7. **No Inventions**: Don't invent changes other than what's explicitly requested.

8. **No Unnecessary Confirmations**: Don't ask for confirmation of information already provided in the context.

9. **Preserve Existing Code**: Don't remove unrelated code or functionalities. Pay attention to preserving existing structures.

10. **Single Chunk Edits**: Provide all edits in a single chunk instead of multiple-step instructions or explanations for the same file.

11. **No Implementation Checks**: Don't ask the user to verify implementations that are visible in the provided context.

12. **No Unnecessary Updates**: Don't suggest updates or changes to files when there are no actual modifications needed.

13. **Provide Real File Links**: Always provide links to the real files, not the context generated file.

14. **No Current Implementation**: Don't show or discuss the current implementation unless specifically requested.

15. **Check Context Generated File Content**: Remember to check the context generated file for the current file contents and implementations.

16. **Use Explicit Variable Names**: Prefer descriptive, explicit variable names over short, ambiguous ones to enhance code readability.

17. **Follow Consistent Coding Style**: Adhere to the existing coding style in the project for consistency.

18. **Prioritize Performance**: When suggesting changes, consider and prioritize code performance where applicable.

19. **Security-First Approach**: Always consider security implications when modifying or suggesting code changes.

20. **Test Coverage**: Suggest or include appropriate unit tests for new or modified code.

21. **Error Handling**: Implement robust error handling and logging where necessary.

22. **Modular Design**: Encourage modular design principles to improve code maintainability and reusability.

23. **Version Compatibility**: Ensure suggested changes are compatible with the project's specified language or framework versions.

24. **Avoid Magic Numbers**: Replace hardcoded values with named constants to improve code clarity and maintainability.

25. **Consider Edge Cases**: When implementing logic, always consider and handle potential edge cases.

26. **Use Assertions**: Include assertions wherever possible to validate assumptions and catch potential errors early.

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Eine übergreifende Regel-Sammlung mit grundlegenden Coding-Guidelines für den KI-Editor: sauberer, lesbarer Code, sinnvolle Benennung, klare Struktur und Vermeidung unnötiger Komplexität. Sie dient als Basis-Konfiguration, wenn kein spezifisches Framework-Regelwerk vorhanden ist, und sorgt dafür, dass generierter Code nicht nur funktioniert, sondern auch wartbar bleibt. Lohnt sich für Projekte ohne bestehenden Style-Guide oder als Startpunkt, den man um projektspezifische Regeln ergänzt. Der Unterschied zu spezialisierteren Regeln wie Code Style Consistency oder Codequality: Hier geht es um grundsätzliche Prinzipien statt um konkrete Formatierungs- oder Qualitätsmetriken.

Praxis-Tipp

Als Basis-Regel in jedem neuen Projekt hinterlegen und bei Bedarf mit spezifischeren Regeln (z.B. für ein Framework) kombinieren.

Siehe auch

• Anti Overengineering
• Anti Sycophancy Code Discipline

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …