Writing code is definitely subjected to individual thinking, logics and perspective. How one writes code is completely depend on their technical and logical skills. Two different people can write the same code in an entirely different tactic (May be both logics of the code are right in their own way). Even two persons can write bad code as well as good code as per the same standard.
In the real world it is most likely possible that one writes the code and same will be read multiple times by many other developers to fix the bugs, improve the features, understand the code. That is why each language has its own style of coding and guideline to make it more meaningful and understandable.
Most of time the Developers struggle to understand the code written by someone else on the team. I have even heard people saying that it’s difficult to read someone else’s code rather writing same from scratch.
I would like to highlight a few compiled techniques in once place to make writing code better.
Classical Method
Classical method is a tools based code review. Developers write their code and submit it for review in some 3rd party tool like review board, Rietveld, or Collaborator for somebody to review the code.
The tool will be used to track code changes comments, patches and review. Someone can merge code to the active branch once it is reviewed. Reviewers can have a look at the code and provide comments and inputs to the relevant piece of code.
The good side is that it can be used for almost all sorts of old source code tools and is very much compatible with most of the version control tools.
The problem with this mechanism is that it needs another tool other then version control system to maintain code review related information.
Integrated Method
To overcome the classical method downside, review systems have been introduced with in version control tools; a very good example of this is GIT. Where there is no (or rarely) 2nd tool needed to perform code review activity. Code review can be done via pull request even before merging. Comments, issues, patches can be tracked within Version control system with same workflow.
 As mentioned earlier everything related to review remains with in the same system and that is the biggest benefit of this system.But this mechanist also needs the same time and effort for someone else to go through the code and sign off.
Extreme Workflow
Pair programming falls under this category. In this Technique, two programmers work as a pair together on one workstation. One writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
This way coding and its review happen at the same time by 2 programmers simultaneously.
Some say that 2 developers working on same code at same time doesn’t make any sense, as they will be end up spending double man hours. It may lead to problems with practical implementation of the technique.
But the good part is that they don’t need to spend extra time to understand and perform code review. It removes to and fro communication between developers. You don’t even need another tool for additional help to submit patch.
In conjunction with review techniques I would like to add one more point about who can review code.
- Leaders review the code: – One of the very common processes is that 2-3 leads will review the code always from the entire team (number depends on team size). They are always whole responsible for performing the review, checking the code before it goes for further consumption.
- Anybody can review the code: – Another technique is that anybody with in team can review the code. Only restriction is that the one is writing code cannot review his own code because this doesn’t make any sense to review your own written code. There is no leader who is responsible for code review. A junior programmer can also review code written by senior, as there is no reason to allot hard role and not allowing others to review code.
Whatever practice we use it is very necessary to have a look at code by another pair of eyes and have code reviewed.
References-
https://en.wikipedia.org/wiki/Code_review
