.cursorrules (deprecated)

1# .cursor
2 
3rules
4 
5# General rules
6 
7- Do not apologize
8- Do not thank me
9- Talk to me like a human
10- Verify information before making changes
11- Preserve existing code structures
12- Provide concise and relevant responses
13- Verify all information before making changes
14 
15You will be penalized if you:
16- Skip steps in your thought process
17- Add placeholders or TODOs for other developers
18- Deliver code that is not production-ready
19 
20I'm tipping $9000 for an optimal, elegant, minimal world-class solution that meets all specifications. Your code changes should be specific and complete. Think through the problem step-by-step.
21 
22YOU MUST:
23- Follow the User's intent PRECISELY
24- NEVER break existing functionality by removing/modifying code or CSS without knowing exactly how to restore the same function
25- Always strive to make your diff as tiny as possible
26 
27# File-by-file changes
28 
29- Make changes in small, incremental steps
30- Test changes thoroughly before committing
31- Document changes clearly in commit messages
32 
33# Code style and formatting
34 
35- Follow the project's coding standards
36- Use consistent naming conventions
37- Avoid using deprecated functions or libraries
38 
39# Debugging and testing
40 
41- Include debug information in log files
42- Write unit tests for new code
43- Ensure all tests pass before merging
44 
45# Project structure
46 
47- Maintain a clear and organized project structure
48- Use meaningful names for files and directories
49- Avoid clutter by removing unnecessary files
50 
51# Clean Code
52 
53Don't Repeat Yourself (DRY)
54 
55Duplication of code can make code very difficult to maintain. Any change in logic can make the code prone to bugs or can make the code change difficult. This can be fixed by doing code reuse (DRY Principle).
56 
57The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system".
58 
59The way to achieve DRY is by creating functions and classes to make sure that any logic should be written in only one place.
60 
61Curly's Law - Do One Thing
62 
63Curly's Law is about choosing a single, clearly defined goal for any particular bit of code: Do One Thing.
64 
65Curly's Law: A entity (class, function, variable) should mean one thing, and one thing only. It should not mean one thing in one circumstance and carry a different value from a different domain some other time. It should not mean two things at once. It should mean One Thing and should mean it all of the time.
66 
67Keep It Simple Stupid (KISS)
68 
69The 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.
70 
71Simple code has the following benefits:
72less time to write
73less chances of bugs
74easier to understand, debug and modify
75 
76Do the simplest thing that could possibly work.
77 
78Don't make me think
79 
80Code should be easy to read and understand without much thinking. If it isn't then there is a prospect of simplification.
81 
82You Aren't Gonna Need It (YAGNI)
83 
84You Aren't Gonna Need It (YAGNI) is an Extreme Programming (XP) practice which states: "Always implement things when you actually need them, never when you just foresee that you need them."
85 
86Even 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:
87you don't need it after all, or
88what you actually need is quite different from what you foresaw needing earlier.
89 
90This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer something based on what you think you might need later on.
91 
92There are two main reasons to practice YAGNI:
93You save time because you avoid writing code that you turn out not to need.
94Your code is better because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.
95 
96Premature Optimization is the Root of All Evil
97 
98Programmers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
99 
100We 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%.
101 
102- Donald Knuth
103 
104Boy-Scout Rule
105 
106Any time someone sees some code that isn't as clear as it should be, they should take the opportunity to fix it right there and then - or at least within a few minutes.
107 
108This opportunistic refactoring is referred to by Uncle Bob as following the boy-scout rule - always leave the code behind in a better state than you found it.
109 
110The code quality tends to degrade with each change. This results in technical debt. The Boy-Scout Principle saves us from that.
111 
112Code for the Maintainer
113 
114Code maintenance is an expensive and difficult process. Always code considering someone else as the maintainer and making changes accordingly even if you're the maintainer. After a while, you'll remember the code as much as a stranger.
115 
116Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
117 
118Principle of Least Astonishment
119 
120Principle of Least Astonishment states that a component of a system should behave in a way that most users will expect it to behave. The behavior should not astonish or surprise users.
121 
122Code should do what the name and comments suggest. Conventions should be followed. Surprising side effects should be avoided as much as possible.
123 
124# Project specific rules
125 
126I'm using angular with standalone components
127I'm integrating novo elements which is the novo-elements module
128 
129Documentation is here: https://bullhorn.github.io/novo-elements/docs/#/home
130Github is here: https://github.com/bullhorn/novo-elements
131 
132I don''t have a module file. I am using standalone components
133 
134@Docs{
135  "library_name": "Novo Elements",
136  "documentation": "https://bullhorn.github.io/novo-elements/docs/#/home"
137}
138 
139@Docs{
140  "library_name": "Novo Elements",
141  "documentation": "https://github.com/bullhorn/novo-elements"
142}
143 
144