.. that is why I've always considered the comments to be an integral part of the code, and when doing code reviews I've refused to approve code changes where the comments are too sparse or where the comments don't match the code.
Amen.
I've mentioned this to Paul before, but Mary Shaw's trick from the old CMU sophomore software engineering course was spot on. You were 3-4 person teams, and the entire class was working on the same project [when I took it, we were building an airline ticketing and equipment reservation system]. The first part required each team to write a specification for the project (which was collected and compared/graded against one that TAs had written). Then the TA gave everyone their "common" spec, which your team started to program for the first part of their spec. Then, two weeks later, the TA handed over your codebase to another team (and you were given the code from another team still). This process was repeated over the 12 weeks, 4 or 5 times as each part of the project was completed.
You were not allowed to use your code base; instead, you had to build on the base provided by the TA for each section. [There was an escape clause of going to the TA if the code you got was a disaster, but then you got a different group's code, and you just lost time working on the earlier version - so it was easier/faster to fix any bugs you found].
People never wanted to be cursed by their classmates. The first thing you always did was do a code review and then run both the tests you had been given and your own against the base to see what you had. As a result, the students learned to write code that was clean, well-tested, and properly commented and documented, because their peers would be reviewing and depending on it. If you were serious, you certainly did not want to get a reputation for writing crap.
The sad part is that I believe CMU discontinued that course a few years ago, because the graduate student TAs hated it. It could be a tremendous amount of work for them.
BTW: IIRC that course was when I had a future Turning Award winner as well as someone else who would make a name in the Multics community as programming partners.
Clem