Skip to content

Comment on Things Everyone Should Do: Code Reviewparent

Comments

There are other things that can be caught by code review, too, like potential performance problems ("why not use a hash table, instead of iterating through the array doing comparisons?"), or code that could be refactored to be shorter and clearer. I've also seen code reviews turn up issues like "you're using library X, but even the author of that library says library Y is better".

We had mandatory code reviews at a previous job. We had a grab someone and have them look at the code in our cube pre-checkin. I found that is was great for finding non-obvious bugs.

For example, our codebase was for a legacy system and there was a lot of knowledge and experience about the code that was never seen without talking to someone that had already dealt with it. So it was not uncommon to have comments about a call being really bad in a loop cause it caused an unexpected database query, or to use weak reference objects here, other such things.

I miss the way code reviews transferred institutional knowledge.

Also, I learned a lot of Eclipse shortcuts through these code reviews.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.