{"id":6946,"date":"2022-09-16T14:31:52","date_gmt":"2022-09-16T06:31:52","guid":{"rendered":"https:\/\/slash.bravefactor.com\/?post_type=resources&p=6946"},"modified":"2024-01-31T16:42:54","modified_gmt":"2024-01-31T08:42:54","slug":"5-things-to-look-for-during-code-review","status":"publish","type":"resources","link":"https:\/\/slash.co\/articles\/5-things-to-look-for-during-code-review","title":{"rendered":"5 Things to look for during code review"},"content":{"rendered":"

Coding is a job that requires hours and hours of work with careful attention allotted to accuracy. However, even the most accurate coder is bound to make the rare mistake now and then, and this is what makes code review important for your development team. For one you can remove a bit of the stress caused by coding when a developer knows his\/her code will be checked, but also it\u2019s your chance to head off any potential issues before they even become issues. Let\u2019s take a look at five key items to look for during code review.<\/span><\/p>\n

Convention<\/h2>\n

Convention, mutual agreement, it\u2019s a must to gain within your development team. Everyone needs to be on the same page when coding so it\u2019s imperative that the team follow the agreed upon coding rules and practices. For example, something as simple as using single vs double quotation marks, declaring short meaningful variable names, maintaining shorter lines of code per file and so on.<\/span><\/p>\n

Consider this case: If we agree as a team to use camel case for a variable name, e.g. \u2013 waitedTime = 3000, but there is included code which is using snake case, e.g. \u2013 waited_time = 3000, now this may not break anything within the code, but it fails to follow the convention which the team has agreed to follow. Code is written by many developers and it\u2019s necessary for it to merge together seamlessly as though it was written by one person. Following the team coding practices aids in development of really clean code that works as it\u2019s designed to, so ensuring everyone’s code follows the agreed upon practices & rules is key.<\/span><\/p>\n

Logic<\/h2>\n

Logic within the code is innately necessary as we gather you\u2019re aware. So you may be thinking, \u201cIf it\u2019s a given, why bother checking during code review?\u201d Well, no one is perfect and as we\u2019re all prone to mistakes, reviewing is a good way to catch those mistakes before they get released and become larger problems. Therefore, it\u2019s good to review how people\u00a0 have written the code for specific logic\/feature flow and complexity.<\/span><\/p>\n

By doing this we can give suggestions to team members on best practices, and comment\/feedback on how the logic should be rewritten according to the acceptance criteria of the review ticket or feature. For example: Consider a situation where there is a requirement to do a login API that verifies the password and generates & responds to the JSON Web token (JWT). In this case, we could review the full logic code as in what the team put in the JWT to encode. If perhaps they accidentally put the password inside the JWT, we can request them to revise that as naturally it will cause security vulnerabilities. So yes, logic is a given, but mistakes are bound to happen so it\u2019s key to examine the logic during code review.\u00a0<\/span><\/p>\n

Complexity<\/h2>\n

The third thing which requires your attention during code review is complexity. In addition for the logic to make sense in the acceptance criteria, you must look out for code complexity in terms of the lines of code and conditional uses in the code. Those conditionals being: if \u2013 else, for loop, sub function or callback. Moreover, you must verify whether or not the code is testable.<\/span><\/p>\n

Let\u2019s consider the following example\u2026 A developer writes the login code in a controller under the MVC pattern, \u201clogin_controller.js\u201d, using logic that contains many responsibilities. Those duties could be any number of things including:<\/span><\/p>\n