Does reading over code I've written make sense to verify it?

Question

After writing some code, I have a habit of scanning it all over once or twice in order to look for any bugs. This is sometimes a painstaking and tedious process, and it takes up time. After reviewing my code, I then run it through my tests to verify it.

Is this a productive way to perform verification? Is it more efficient if I just run my code through tests, and if it passes all of them then the code can probably be considered correct? The reason I don't do this is that my tests might not always cover every single edge case, and thus there's a chance my program could be wrong.

Any advice on how I can improve my verification methods would be appreciated. If it is a good idea to scan over code, when should I be doing it (and how many times)?

Answer 1

Tests will ensure correctness (minus your uncovered edge cases), but it's not enough for the code to be correct; it must also be as readable/understandable as possible for you and anyone reading it after you. Even with a stringent code review process on my team, I always perform my own self-review before creating a pull request. In doing so, I often find ways to make the intent of the code clearer before sending it to review.

This is a personal question though. It's possible that some developers are capable of writing very readable code from the start. If so, that's great. However, most of us will likely be able to find some improvements after the feature work is done. As such, I highly recommend performing at least a cursory self-review, or a full review if your team does not have a formal code review process in place.

As for what makes code more "readable", this can be very subjective. The goal is to make it readable for as large an audience of developers as possible. There are many resources available that describe techniques for writing clean code, such as the book by Bob Martin, which is generally well-accepted (albeit dated) for this purpose.

To answer your questions more directly: You should not need to review your code visually to check for bugs, but you should review your code visually to ensure that it is readable. There is no magic number for how long you should spend on this review; as the discovery rate of readability problems drops, you're nearing the end. My advice is to write tests for as many reasonably-expected execution paths as possible, and check manually for improvements to readability.

Answer 2

You can write tests and call it verification.

You can write proofs and call it verification.

But none of them mean anything if the code, the tests, and the proofs aren't all readable.

The reason we write tests is to improve the readability of the code. Same with proofs. The reason we forbade goto was to improve the readability of the code. It's all about readability.

So the only good verification of code is to read it. The reason you read and reread the code is because you're looking at the code differently. Every time you think of a new way to think of the code you should reread it.

If you find it painstaking and tedious to read you should rewrite the code to be more readable.

You should also rewrite your tests to be more readable. You should write tests that show people how to read the code. Where to start. What to expect. The scope. Good tests help you read code.

Don't haze the next person who reads your code with hard to understand code. Write like you want to be nice to them. Someday they may be you.