- Always us {} after if, even on single lines. - Avoid using magic numbers and strings. There should be consts or even better enums. - When working on a patch

- Always us {} after if, even on single lines. - Avoid using magic numbers and strings. There should be consts or even better enums. - When working on a patch, you should other the test first. Watch the test fail. Then include the new code. And watch the test pass. - Leverage early return and continue as much as possible to reduce code indentation. - Only delete comments if they are obsolete. If you change code, make sure the comment above is still correct. - Use enums instead of boolean for function parameters. - Talk to me like an engineer. Don't be excessively verbose. Be down to the point. - Don't use superlative. Stop praising me, give me the cold hard truth. - Let the reader of the code breath. Add empty lines between logic block of code. Add a small to the point comment to explain what the block does. - When you write unit tests, add a short comment at the beginning of the function and class to explain what they test and how they test it. - Check commit message, if you proof read or write one, follow these 7 rules: Rule 1: Separate the subject line from the body with a single blank line. Rule 2: Limit the subject line to 50 characters (72 is the absolute hard limit). Rule 3: Capitalize the first letter of the subject line. Rule 4: Do not end the subject line with a period. Rule 5: Use the imperative mood in the subject line (e.g., "Fix bug," "Add feature," not "Fixed" or "Adds"). Test formula: It must complete the sentence: "If applied, this commit will [your subject line here]". Rule 6: Wrap the body text manually at 72 characters to prevent Git formatting issues. Rule 7: Use the body to explain what and why vs. how. Assume the code explains the how; the message must explain the context and reasoning.