Skip to main content

"Verifying overall correctness manually via code review however is very difficult and time-consuming, if it is even possible at all."

Verifying overall correctness manually via code review however is very difficult and time-consuming, if it is even possible at all.

Many years ago, it was actually my job to do exactly that by grading students' homework. And while many delivered some reasonable quality with a bug here and there, there were two who stood out. Both always submitted code that had no bugs. One submitted code that I could read from top and bottom at high speed and mark as 100% correct with zero effort. The other submitted code that was one WTF after the other, but somehow managed to avoid any bugs. An absolute pain to mark.

Today the second one would have his code rejected in a code review. If verifying correctness is very difficult and time-consuming, then that is a problem with the code. A decent programmer would figure out how to solve a problem (takes time X) and before giving it to a code review refactor it so that it doesn't just do the job, but obviously does the job. That takes much less than X in time and saves a lot of time in the future. Often by uncovering bugs before they even go to the stage of a code review. Next by making the code review a lot quicker. And all the time in the future by making the code easier to adapt.

Another answer said that some people's code could be refactored 10 times, becoming more readable each time. That's just sad. That's a developer who should look for a different job.

"Verifying overall correctness manually via code review however is very difficult and time-consuming, if it is even possible at all."

Many years ago, it was actually my job to do exactly that by grading students' homework. And while many delivered some reasonable quality with a bug here and there, there were two who stood out. Both always submitted code that had no bugs. One submitted code that I could read from top and bottom at high speed and mark as 100% correct with zero effort. The other submitted code that was one WTF after the other, but somehow managed to avoid any bugs. An absolute pain to mark.

Today the second one would have his code rejected in a code review. If verifying correctness is very difficult and time-consuming, then that is a problem with the code. A decent programmer would figure out how to solve a problem (takes time X) and before giving it to a code review refactor it so that it doesn't just do the job, but obviously does the job. That takes much less than X in time and saves a lot of time in the future. Often by uncovering bugs before they even go to the stage of a code review. Next by making the code review a lot quicker. And all the time in the future by making the code easier to adapt.

Another answer said that some people's code could be refactored 10 times, becoming more readable each time. That's just sad. That's a developer who should look for a different job.

Verifying overall correctness manually via code review however is very difficult and time-consuming, if it is even possible at all.

Many years ago, it was actually my job to do exactly that by grading students' homework. And while many delivered some reasonable quality with a bug here and there, there were two who stood out. Both always submitted code that had no bugs. One submitted code that I could read from top and bottom at high speed and mark as 100% correct with zero effort. The other submitted code that was one WTF after the other, but somehow managed to avoid any bugs. An absolute pain to mark.

Today the second one would have his code rejected in a code review. If verifying correctness is very difficult and time-consuming, then that is a problem with the code. A decent programmer would figure out how to solve a problem (takes time X) and before giving it to a code review refactor it so that it doesn't just do the job, but obviously does the job. That takes much less than X in time and saves a lot of time in the future. Often by uncovering bugs before they even go to the stage of a code review. Next by making the code review a lot quicker. And all the time in the future by making the code easier to adapt.

Another answer said that some people's code could be refactored 10 times, becoming more readable each time. That's just sad. That's a developer who should look for a different job.

Source Link
gnasher729
  • 49.4k
  • 4
  • 71
  • 137

"Verifying overall correctness manually via code review however is very difficult and time-consuming, if it is even possible at all."

Many years ago, it was actually my job to do exactly that by grading students' homework. And while many delivered some reasonable quality with a bug here and there, there were two who stood out. Both always submitted code that had no bugs. One submitted code that I could read from top and bottom at high speed and mark as 100% correct with zero effort. The other submitted code that was one WTF after the other, but somehow managed to avoid any bugs. An absolute pain to mark.

Today the second one would have his code rejected in a code review. If verifying correctness is very difficult and time-consuming, then that is a problem with the code. A decent programmer would figure out how to solve a problem (takes time X) and before giving it to a code review refactor it so that it doesn't just do the job, but obviously does the job. That takes much less than X in time and saves a lot of time in the future. Often by uncovering bugs before they even go to the stage of a code review. Next by making the code review a lot quicker. And all the time in the future by making the code easier to adapt.

Another answer said that some people's code could be refactored 10 times, becoming more readable each time. That's just sad. That's a developer who should look for a different job.