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)?

  • Passing and consolidate unit tests are way more productive than just reading and reviewiing. – πάντα ῥεῖ May 14 '18 at 21:43
  • 2
    Unit tests are complementary to code review, not a replacement for it. While tests are great for validating correctness, they will not highlight readability issues. – Kyle McVay May 14 '18 at 21:56
  • If you are talking about formal verification, that is entirely different. That requires proofs. But any review helps. – Frank Hileman May 14 '18 at 23:50
  • Passes test, must be correct, have not had such a good laugh for a long time. My experience is very few software products ship with failing tests, but most are full of defects. – mattnz May 15 '18 at 9:00
  • @mattnz I never said passing tests implies that the program "must be correct". The reason I had an issue in the first place was that I was unconfident my tests were good enough. – Inertial Ignorance May 16 '18 at 7:02

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.

  • I think reviewing code to just check readability is a good idea. The main reason my self-reviews were so tedious was that I was trying to verify correctness by reading. In complicated code, this is nearly impossible. – Inertial Ignorance May 14 '18 at 22:27
  • Were you starting your reviews with specific edge cases already in mind, or looking over the code in general to find things that you missed? – Kyle McVay May 14 '18 at 22:46
  • Just looking over the code in general. – Inertial Ignorance May 14 '18 at 22:49
  • Well accepted? Not at all. – Frank Hileman May 14 '18 at 23:50
  • Would you care to substantiate that claim? There are literally hundreds of positive reviews for the book, including in-depth analyses on various dev blogs. 4.5 stars on Amazon, 4.4 on GoodReads, with over 10k reviews between those two sites. That sounds like "generally well-accepted" to me. – Kyle McVay May 14 '18 at 23:59

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.