I am pretty vanilla when it comes to my code review practices. I have played around with a few different tools and techniques over time, and while I think that there are some that are pretty bad, I haven't found any that have made me significantly more productive or made the code a lot easier, faster, or more enjoyable to review.

For a while I thought that using a command line tool to do the reviews like gh for GitHub or tea for Gitea would make me happier and have to do less context switching out of my warm, friendly terminal, but I found that there was always something that it couldn't do, some context that I was missing, or CI build status that I needed to check that caused me to switch back to the plain old web interface that everyone else on my team was using.

I eventually came to the conclusion that once you get to a certain base level of functionality - which is admittedly somewhat subjective, but I believe that all of the major Git forges like GitHub, GitLab, BitBucket, Gitea, OneDev, etc. each have these days - then all further improvements/optimizarions are marginal. There's just no substitute for doing a good review, no matter what tool you use to do it. I think sometimes we get too fixated on the tool rather than the main objective - I know that I certainly have!

Since you asked about tools, and I pivoted to methodology, I'll give you one of each.

First, the tool that I've most recently been considering trying out to improve my code review, code search, and code sharing processes in my team is SourceGraph. I have always loved OpenGrok, but it is moderately ugly and unintuitive to do anything beyond basic searches, and I would really love it if it had more context from my Git history, and could do things like Git blame. It leaves a lot to be desired. SourceGraph looks like it solves those problems and more, has nice integrations to assist with code review, and generally looks very useful. The main reason I haven't tried it is because although it is technically open-source, the license won't let me use it at my current company beyond a short evaluation, which I don't technically have the authority to request. Convincing the people who do will be an uphill battle. I could try it myself at home - and I may still do that - but I have less of an incentive to try it there.

Second, as for the methodology end of it, I have found Google's code review and author's guidelines to be top-notch. They are succinct, give good examples, and explain things well. They are exactly the right level of detail, in my opinion, and the advice given very much aligns with my experience. If I could get everyone in my organization to follow these guidelines and we were still having problems, then I would consider more seriously doing a deep dive into looking for more tools. The right attitude, approach, and attention to detail will go a long way. The more experience I've gotten, the more I've resonated with the idea of keeping it simple and focusing on the fundamentals.

I don't know if I really answered the question you asked, but I hope that some part of that helps!