- Clean Code in C#
- Jason Alls
- 442字
- 2025-04-04 12:56:14
Preparing code for review
Preparing for a code review can be a right royal pain at times, but it does work for better overall quality of code that is easy to read and maintain. It is definitely a worthwhile practice that teams of developers should carry out as standard coding procedures. This is an important step in the code review process, as perfecting this step can save the reviewer considerable time and energy in performing the review.
Here are some standard points to keep in mind when preparing your code for review:
- Always keep the code review in mind: When beginning any programming, you should have the code review in mind. So keep your code small. If possible, limit your code to one feature.
- Make sure that all your tests pass even if your code builds: If your code builds but you have failing tests, then deal immediately with what's causing those tests to fail. Then, when the tests pass as expected, you can move on. It is important to make sure that all unit tests are passed, and that end-to-end testing passes all tests. It is important that all testing is complete and gets the green light, since releasing code that works but was a test fail could result in some very unhappy customers when the code goes to production.
- Remember YAGNI: As you code, make sure to only add code that is necessary to meet the requirement or feature you are working on. If you don't need it yet, then don't code it. Only add code when it is needed and not before.
- Check for duplicate code: If your code must be object-oriented and be DRY and SOLID, then review your own code to see whether it contains any procedural or duplicate code. Should it do so, take the time to refactor it so that it is object-oriented, DRY, and SOLID.
- Use static analyzers: Static code analyzers that have been configured to enforce your company's best practices will check your code and highlight any issues that are encountered. Make sure that you do not ignore information and warnings. These could cause you issues further down the line.
Most importantly, only check your code in when you are confident that your code satisfies business requirements, adheres to coding standards, and passes all tests. If you check your code in as part of a Continuous Integration ( CI) pipeline, and your code fails the build, then you will need to address the areas of concern raised by the CI pipeline. When you are able to check in your code and the CI gives the green light, then you can issue a pull request.