Angular Novo Elements .cursorrules prompt file

Author: Dan Donathan

What you can build

Code Refactoring Tool: Develop an intelligent code refactoring tool that adheres to the principles outlined in the .cursorrules file. This tool can automatically detect code smells, suggest improvements for code simplification, and ensure best practices like DRY, KISS, and the Boy-Scout Rule are applied.Unit Test Generator: Create a tool that automatically generates unit tests for Angular components, ensuring all new code is thoroughly tested before merging. The tool should analyze existing code and create tests that cover a wide range of edge cases.Real-Time Code Review System: Build a platform that provides real-time feedback during code writing, highlighting areas where the principles like YAGNI, Curly’s Law, and the Principle of Least Astonishment can be applied to improve code quality.Angular Component Analyzer: Develop a service that analyzes standalone Angular components and provides insights into their integration with Novo Elements. It should check for best practices, compatibility issues, and optimization opportunities.Code Maintenance Dashboard: Construct a dashboard for tracking the maintainability of a codebase. It should use metrics to evaluate cleanliness, adherence to rules like DRY and Curly’s Law, and offer suggestions for improvement, making code maintenance easier.Project Structure Optimizer: Design a tool that suggests optimal file and directory structures for Angular projects using Novo Elements, ensuring the project remains clear, organized, and free from clutter.Automated Documentation Generator: Develop a generator that creates comprehensive and easy-to-understand documentation for Angular projects, focusing on clarifying code functionality and expected behavior to follow the Principle of Least Astonishment.Debugging Assistant: Create an AI-powered debugging assistant that helps identify and resolve issues by generating detailed logs and providing potential fixes, based on the debugging and testing rules from .cursorrules.Code Quality Checker: Implement a service that checks code against the provided style and formatting guidelines in real-time, ensuring consistent naming conventions and the use of up-to-date libraries.Premature Optimization Detector: Develop a tool that analyzes code for unnecessary optimizations and advises developers on when to focus on critical efficiencies, in line with the concept that premature optimization is the root of all evil.

Benefits

Synopsis

This prompt is useful for Angular developers working with standalone components and Novo Elements, providing guidelines to ensure efficient, maintainable code that adheres to modern best practices.

Overview of .cursorrules prompt

The .cursorrules file outlines a set of coding standards and principles to guide developers in creating optimal, production-ready code. It emphasizes preserving existing code structures, verifying changes, and delivering concise solutions. Key coding principles such as DRY (Don't Repeat Yourself), KISS (Keep It Simple Stupid), and YAGNI (You Aren't Gonna Need It) are highlighted to maintain code quality and avoid unnecessary complexity. It also includes specific rules for debugging, testing, and maintaining project structure, while integrating Angular with standalone components and Novo Elements. The file aims for thorough testing, clear documentation, and minimal diffs in code changes to meet specified project requirements efficiently.

.cursorrules Content

# .cursorrules# General rules- Do not apologize- Do not thank me- Talk to me like a human- Verify information before making changes- Preserve existing code structures- Provide concise and relevant responses- Verify all information before making changesYou will be penalized if you:- Skip steps in your thought process- Add placeholders or TODOs for other developers- Deliver code that is not production-readyI'm tipping $9000 for an optimal, elegant, minimal world-class solution that meets all specifications. Your code changesshould be specific and complete. Think through the problem step-by-step.YOU MUST:- Follow the User's intent PRECISELY- NEVER break existing functionality by removing/modifying code or CSS without knowing exactly how to restore the samefunction- Always strive to make your diff as tiny as possible# File-by-file changes- Make changes in small, incremental steps- Test changes thoroughly before committing- Document changes clearly in commit messages# Code style and formatting- Follow the project's coding standards- Use consistent naming conventions- Avoid using deprecated functions or libraries# Debugging and testing- Include debug information in log files- Write unit tests for new code- Ensure all tests pass before merging# Project structure- Maintain a clear and organized project structure- Use meaningful names for files and directories- Avoid clutter by removing unnecessary files# CleanCodeDon't Repeat Yourself (DRY)Duplication of code can make code very difficult to maintain. Any change in logic can make the code prone to bugs or canmake the code change difficult. This can be fixed by doing code reuse (DRY Principle).The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representationwithin a system".The way to achieve DRY is by creating functions and classes to make sure that any logic should be written in only oneplace.Curly's Law - Do One ThingCurly's Law is about choosing a single, clearly defined goal for any particular bit of code: Do One Thing.Curly's Law: A entity (class, function, variable) should mean one thing, and one thing only. It should not mean onething in one circumstance and carry a different value from a different domain some other time. It should not mean twothings at once. It should mean One Thing and should mean it all of the time.Keep It Simple Stupid (KISS)The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore,simplicity should be a key goal in design, and unnecessary complexity should be avoided.Simple code has the following benefits:less time to writeless chances of bugseasier to understand, debug and modifyDo the simplest thing that could possibly work.Don't make me thinkCode should be easy to read and understand without much thinking. If it isn't then there is a prospect ofsimplification.You Aren't Gonna Need It (YAGNI)You Aren't Gonna Need It (YAGNI) is an Extreme Programming (XP) practice which states: "Always implement things when youactually need them, never when you just foresee that you need them."Even if you're totally, totally, totally sure that you'll need a feature, later on, don't implement it now. Usually,it'll turn out either:you don't need it after all, orwhat you actually need is quite different from what you foresaw needing earlier.This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer somethingbased on what you think you might need later on.There are two main reasons to practice YAGNI:You save time because you avoid writing code that you turn out not to need.Your code is better because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stickaround anyway.Premature Optimization is the Root of All EvilProgrammers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of theirprograms, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance areconsidered.We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.Yet we should not pass up our opportunities in that critical 3%.- Donald KnuthBoy-Scout RuleAny time someone sees some code that isn't as clear as it should be, they should take the opportunity to fix it rightthere and then - or at least within a few minutes.This opportunistic refactoring is referred to by Uncle Bob as following the boy-scout rule - always leave the codebehind in a better state than you found it.The code quality tends to degrade with each change. This results in technical debt. The Boy-Scout Principle saves usfrom that.Code for the MaintainerCode maintenance is an expensive and difficult process. Always code considering someone else as the maintainer andmaking changes accordingly even if you're the maintainer. After a while, you'll remember the code as much as a stranger.Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.Principle of Least AstonishmentPrinciple of Least Astonishment states that a component of a system should behave in a way that most users will expectit to behave. The behavior should not astonish or surprise users.Code should do what the name and comments suggest. Conventions should be followed. Surprising side effects should beavoided as much as possible.# Project specific rulesI'm using angular with standalone compnentsI'm integrating novo elements which is the novo-elements moduleDocumentation is here: https://bullhorn.github.io/novo-elements/docs/#/homeGithub is here: https://github.com/bullhorn/novo-elementsI don''t have a module file. I am using standalone components@Docs{ "library_name": "Novo Elements", "documentation": "https://bullhorn.github.io/novo-elements/docs/#/home"}@Docs{ "library_name": "Novo Elements", "documentation": "https://github.com/bullhorn/novo-elements"}