5 ms·
"there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors" But you're totally right. I was watching my friend co
by civilian 12y ago
"there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors"
But you're totally right. I was watching my friend code last night, we both have the same # of years experience, and I was like "what does that function name even mean? How about 'FindNeighbors' instead of 'CheckNeighbors' ". I'm sure I do the same thing in my own code.
If you still teach, do you ever have your students do code review on eachother's code?
- ggchappell 12y ago> If you still teach, do you ever have your students do code review on eachother's code? Yes, I teach. No I haven't done that. But it's a great idea. I'll think about it. <ggchappell proceeds to think about it>
- civilian 12y agoIn the more hardcore-about-code-review job I had, the code reviewer was as responsible for bugs / broken stuff that came out as the person who wrote the code. And in that job we didn't just read the code briefly, you'd load up the branch and test their code. I'm not sure that it was the best practice, it slowed everything down and led to a more formal culture. If you do this, in order to incentivize the code reviewer you might actually make 10% of the grade based on the code submitted by the person they reviewed. (Granted that could be kind of harsh, and I always hated group projects in school.)
- honestcoyote 12y agoProbably best to make code review an extra credit exercise because you don't want to ever penalize a good student by tying their rewards to the actions of someone who might be slacking.