Code Review for Researchers Closing Remarks v a lerio.m a ggio@bristol. a c.uk @leriom a ggio V a lerio M a ggio 

Thank You, very much! Image Credits: bounteous.com/insights/2019/06/11/code-review-limbo-how-low-should-you-go 

Summary (1/) Why Code Review matters ? • Code Review fosters Knowledge Sharing • Ensures Consistency (design & implementation) 
 • Code Review bene f its overall code quality • (also) aids track of changes: pre-commit and post-commit CR 
 • Code Review fosters Collaborative work • Mentoring new-comers (e.g. new lab members) 
 

Summary (2/) Why Code Review matters ? • Code Review lowers the barriers • There is no shaming nor blaming in CR! • Helps f ighting the Imposter Syndrome (more on this in the next slide) 
 • (Most compelling reason for Code Review) 
 Find defects as early as possible in your development process 

Summary (3/) How to Code Review ? Re Imposter Syndrome, i.e. fear of being found out as “Bad Programmer” • Code Review should help to set up a safe environment • It is a tool we should use to grow as better SE, and scientists. • (therefore) Rule #1: Being Respectful 
 • Code Review is not all about defects • Great practice to also recognise the good parts of a code listings! 

Summary (4/) How to Code Review ? (more practically) 1) Write some code (😏 ) 2) Ask someone to look at the code 3) Incorporate their feedback into your code 4) Repeat 2 and 3 until satisfactory for both parties 5) Enjoy 🎉 Code Review Loop • Code Review can be carried out IRL or remotely 
 (e.g. GitHub or ReviewBoard) • Communicate Goals and Expectations • Know what to look for in a CR • Give feedback and Helps • Make sure to include everyone in the process • Every contribution counts 
 (like in Open Source) (short) Tips list 

Getting Started with Code Review (1/) Find Reviewers Find Reviewers: • In your research group • In your lab • In your Institution • Ask your PI. • Organise a Coding-Group • Reaching out to SSI and RSEs • Join CR Network 

Getting Started with Code Review (2/) Choose a Code to Review Author: • Aim for 40/45 mins, ~200LOC • Choose depending on your expectations • Pick a part you are not con f ident about (or very con f ident with) • Pick a part that is representative of your programming practice • Lean towards Pre-Commit CR in your dev. cycle Reviewer: • Fast interactions and (reasonably) short comments (esp. for online CR) • Explain Why • Give Guidance • LGTM w/ Comments 

Getting Started with Code Review (3/) Start with Conversation and Agree on a Plan • (If needed) Introduce yourself: provide background and relevant experience • State Expencations and Goals • Provide the reviewer with any context or pre-requisite about your code • e.g. this is a heavily numerical module that f its within a larger ecosystem. I have been working on this for the past couple of days. • e.g. This is a script that simpli f ies my own personal experimental setup, I wrote it 2 years ago from another student's script. • Prefer Live Discussion (whenever possible) • Give the reviewer some time to make their own independent ideas • (Ultimate Goal) Make Code Review a Standard Development Practice 

(some) References • Google Engineering Practices Documentation 
 https://google.github.io/eng-practices/ • Code Review as a Simple Trick to Enhance Reproducibility, Accelerate Learning, and Improve the Quality of Your Team’s Research (Vable et al, 2021) 
 https://academic.oup.com/aje/article/190/10/2172/6218064 • Code Reviewing in the Trenches (MacLeod et al 2017) 
 http://chisel.cs.uvic.ca/pubs/macleod-IEEESoftware2017.pdf • A recent ACM talk by M. Greiler (Youtube) 
 https://www.youtube.com/watch?v=gRR-UhusQe8 • A old, short but popular blog post by Je ff Atwood, see also the discussion underneath 
 https://blog.codinghorror.com/code-reviews-just-do-it/ • Another rather popular couple of posts by M. Lynch 
 https://mtlynch.io/human-code-reviews-1/ • What to look for in a code review (Trisha Gee, JetBrains 2017) • Code Review By and For Scientists (Petre and Wilson 2014) 
 https://arxiv.org/abs/1407.5648