Thread

1. n4r9 · 1790545492 · focus · HN ↗

   There&#x27;s been a lot of talk about the purpose of code review recently. It makes sense in the face of AI. Heres a link that was submitted a little while ago: <a href="https:&#x2F;&#x2F;mathstodon.xyz&#x2F;@mjd&#x2F;115096720350507897" rel="nofollow">https:&#x2F;&#x2F;mathstodon.xyz&#x2F;@mjd&#x2F;115096720350507897

   And in response I wrote a non-exhaustive checklist of things that a code review can look for:

   - Does it functionally achieve what it sets out to (as per tacker issue or PR description)?

   - Does it have extraneous code? Leftover debug prints, private API keys etc...

   - Does it have any obvious defects? Memory leaks, un-handled edge cases, security flaws, obsolete API calls, etc...

   - Could it be more understandable? Add&#x2F;remove abstractions, better variable&#x2F;method names, more&#x2F;less functional etc...

   - Is the style consistent with the codebase and&#x2F;or style guidelines?

   - Are there obvious performance improvements? Hashset instead of list, lazy evaluations, etc...

   - Is it sufficiently well tested?

   I think LLMs are okay at most of these, and worst at the first.

   1. nnevatie · 1790580887 · focus · HN ↗

      I think we&#x27;re kind of missing a layer of testing, that should sit above unit and integration tests.

      Something akin to &quot;meta-tests&quot;, which are not about testing the code itself, but the approaches taken by the implementation - i.e. architecture, understandability, terseness, etc.

      These tests would operate on the source code level, even when testing code for a compiled language.

Unofficial Hacker News client; not affiliated with Y Combinator.