Code Revision

Blog X.

When you finish writing the code or while, you have to do before running the program is the revision of it. What is it? and why would we do that?. We have to review the code by reading and viewing parts of its code, but why? because we are all humans, we can make many mistakes and by reading the code, we can realize of some errors that you made or strengthen the security of the code.

There are several types of reviewing the code:

• Formal inspection: is a formal process which involves a careful and detailed execution with multiple participants and multiple phases. Formal code reviews are the traditional method of review, in which many people attends to a several meeting to review the code line by line.

• Over the shoulder: one developer looks over the author’s shoulder as the latter walks through the code.

• Email pass around: source code management system emails code to reviewers automatically after checkin is made.

• Walkthroughs: usually with an emphasis on the presentation and discussion of the code in a meeting.

• Pair-Programming:  two authors that develop code together at the same workstation, is very similar to code review but not a code review in the narrow sense.

• Tools: you can use some external programs to revise your code, it saves some time and helps to sustain code review process without getting stressed out.

What are the benefits of reviewing the code?

• Finding bugs early: when they are cheap to fix.

• Coding standards compliance: Code review helps to maintain consistent coding style across the company.

• Teaching and sharing knowledge: During review team members gain better understanding of the code base and learn from each other.

• Consistent design and implementation: Peer review helps to maintain a level of consistency in software design and implementation.

• Higher software security: Applications that require a high level of security benefit from targeted security reviews.

• Team cohesion: Review discussions save team members from isolation and bring them closer to each other.

• Confidence of stakeholders: You build confidence of stakeholders about the technical quality of the execution.

Here is the blog of 1 programmer that explains the 10 Reasons Why Code Reviews Make Better Code and Better Teams:
https://simpleprogrammer.com/why-code-reviews-make-better-code-teams/

Also, there are some tips for you to practice:

• Review fewer than 400 lines of code at a time: The brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find defects diminishes.

• Do not review for more than 60 minutes at a time: When people engage in any activity requiring concentrated effort over a period of time, performance starts dropping off after about 60 minutes.

• Authors should annotate source code before the review: Authors should annotate code before the review occurs because annotations guide the reviewer through the changes, showing which files to look at first and defending the reason behind each code modification.

• Use checklists: are the most effective way to eliminate frequently made errors and to combat the challenges of omission finding.

• Foster a positive code review culture: it is very possible to getting stressed and become furious and you can treat other people with anger, so it is important to be positive.