Ask HN: Where can I learn how to get better at code reviews?

Code reviews to me are about, in ascending order of abstraction:

1. Code cleanliness. Stylistic issues that should ideally be handled by a linter but may get missed. Did they name their variables according to the styleguide (camelCase vs snake_case), did they use type annotations where appropriate, did they indent their code correctly.

2. Code smell. Is the dev using a hack in the language or some other bad behavior (for example, casting typescript values to unknown or any, where it can be avoided? Are they passing void* inappropriately in C/C++?)

3. Potential bugs. Are they checking for null pointers before dereferencing? Are they checking the size of an array before accessing it by index?

4. Architecture. Are they writing code in a pattern that is common to the rest of the code base? If this project is trying to use functional programming, are they introducing global state or mutability? If this project is object oriented are they using constructors correctly or are they creating factory/builder classes when appropriate? This one depends on the philosophy of the team

5. Missing work. Should they add doc comments? Should they add unit tests? Integration tests? QA information? Did they follow all the procedures for releasing code? Is the work in their code reflective of well-written requirements in the ticket?

1. Can I understand it - this is a low bar as I don't do much coding anymore and often the teams I'm working with use different languages / tooling to what I'm familiar with. Try to avoid anything too clever!

2. I try to think of stuff other than the base functionality, often non functional requirements e.g. storage of system config and secrets and where, performance, security, error codes, naming, modularisation. A lot of my thinking comes from reading code complete when I 1st started coding.

3. Not really part of code review but I try and get an idea of whether the developer understands the reason for their code in the wider context of the project.

What you're asking is a bottom-up approach and I'm not sure if it can help you in this context. What you may get in return is a bunch of theoretical concepts that may or may be relevant to your case.

Try to find answer using top-down questioning. Perhaps ask questions to the party that gave you this feedback (Ask yourself first), Was I too slow? Did I miss out on an important context? What other specific thing was noticed?

Who told you this and what other details did they give you?

What prevents you from doing better code reviews?