- 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.
In comments don't use prepositions (that, it, those) e.g. "It serves those file migration methods". Instead say e.g. "This method is intended to serve methods x,y and z or any method that has set up a migration source and sink".
- 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.