I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.
That seems incredibly heavy handed and not helpful in the learning process. I was a professor's aid for several programming courses and many students simply made comments like that constantly because it helped them drill it into their head what it did. It's a little annoying but it doesn't hurt the readability.
Automatically failing them on a second turn-in seems very anti-student and anti-learning to me. Teaching through negative reinforcement is the worst way to teach.
First time we talk about why I don't want "the what" comments, only "the why" comments. If they still do it in the next handin it's a fail unless they've explicitly provided me with a reasonable reason to do it.
Your comment merits a failing mark, downvotes, because you made the same subjectively wrong statement twice.
i++ //increment variable because used clicked
Working is the lowest bar of quality.
Any interviewee is going to make assumptions about what the interviewer wants. Some of these assumptions will be wrong and some will not be worth the time to ask about (like commenting style). If the interviewee solved the problem and/or displayed a desirable level of competence that's good enough. Interviewers do the coding exercise merely to screen out people that have grossly misrepresented their skills.
On the internet folks like to imagine they're in a position to "immediately reject" a job applicant because of a single "red-flag" that indicates some profound shortcoming. This is rarely the case.
I find it absolutely destroys readability. It is incredibly hard to follow code written twice.
Another thing is, when I was learning to program, commenting was something I used to keep things light. Sometimes inside jokes or random bits of code that were terrible that would make me laugh once I had the final solution. In my opinion, unless the assignment was designed to teach proper comments, why not let students be creative with their comments, even if its redundant to you.
That said, in a test when hand writing code it should only be pseudo code. Expecting learners to write syntax correct code by hand is stupid.
> why not let students be creative with their comments, even if its redundant to you.
I wasn't keeping that in mind. Thats makes a lot of difference. Pretty sure I studied under the same rules.
A better idea would be to get a standard code style for all course...
I told him he was wrong and argued with him on more than one occasion. In the end, I just did it his way because there wasn't a good alternative.
Might be fun to do some light ad hoc parsing.
Also, with that rule, I can't resist
// this line left intentionally blank. // this line left intentionally non-blank.Ironically, that is quite a bit like the real world.
Simplistic comments actually help a lot when learning (even if they are just a reinforcement). Quite often our students write the comments first and then fill in the code which is perfectly fine.
It's also more interesting to let them freeflow it and then explain later why it might not be a good idea. The learning effect is stronger if they can go back and read their own overcommented code.
It's a nightmare of irritation.
You could easily replace "students" with "coders" and that statement is still true. Just an observation.