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.
> It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail
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.
I felt when I was a student that some teachers just wanted everyone to know how clever they were and sometimes that could be achieved by putting someone else down. Someone who wasn't in a position to talk back. The good teachers gave criticism, pointed to the code standards for the course and were fair in their marking. The best teachers asked questions that made the students produce better work and took time to explain and discuss. They all knew which category they were in.
You can see my reply to the parent comment. I always sit down and talk with the students, but for us to talk about the code, we need to be able to read the code. Unneeded comments make it significantly harder to read code.
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.
Programming is not a science. "Pad to multiple of 256 otherwise libX will fail" is exactly what a comment is for, and it is the "why", no the "what" - the what is already readable in the code.
I think folks are getting hung up on nitpicking the comments. I never heard of anyone getting rejected strictly because of a stray unnecessary comment in a code test for hiring.
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 sit down with them individually and talk about the handin. For any meaningful feedback to happen, we need to see the code. This is not programming 101, but courses that require you to have passed advanced programming, so I expect them to hand in without comments like this:
i++ //increment variable because used clicked
It's harmful for readability and takes a lot longer to read. If they hand me a second handin with such comments, after our first session, I'm not going to tell them again.
While I might not agree with the GP that this should be an automatic failure, I do think it is very important to emphasize to students that when the code is working, they are not done. They still need to go back, re-format, clean things up, and possibly add tests.
I agree with the other commenters that say thats a bit harsh to completely fail them. I was in my third CS class in college and I left out a semi colon on a test and my teacher said, none of the code would work from here, so the answer is just 100% wrong. Even though the rest was 100% correct. I made the argument that if I was sitting at a computer, that would have been less than a 5 second mistake, or something I would have noticed in the syntax highlight, but he insisted it was a complete fail. I never understood that, but I think it relates back to the days when the professor learned on punch cards and one small error was more costly than today.
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.
Failing for missing semi colon seems harsh, but in reality, when students are told to run their code before handing it in, a missing semi colon tells you exactly that the students didn't run the code. If a student fails to meet simple basic requirements, they cannot expect some leeway.
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.
Because I have to read every comment, decide if it's relevant or not, and delete it if it isn't. "End of line comments" on every single line is not helping anyone - "using for loop to iterate over the array" is bloody useless, because it's right there in the code. Keep in mind this is CS students at least 2 years in.
As someone that was a student until last year, the real hard problem is that we have teachers that want this type of comments.
Having different standards for different teachers the same day is a lot of context switching...
A better idea would be to get a standard code style for all course...
My school actually had standard coding styles for each language they taught. Naturally, they all wanted a metric fuckton of comments (luckily the TAs didn't care as much about the comments part of those guides).
Particularly with beginners, I think there's a lot of "What were they thinking when they wrote this??" going on when a professor or TA reads code that is completely unintuitive (Take a look at /r/learnprogramming for some examples). Having comments everywhere makes it easy to say, "Oh! S/he was trying to reset all of the variables in the program by calling main(null); (actual example from the subreddit). How would you ever know that without a comment explaining why main(null); is called in the middle of a class?
Did you sit down with student and try to understand why they wrote comments like that, explain exactly why comments like that where bad and try to show them a better way, or did you just fail them and hope they'll work out all those things by themselves?
Why not run a parser that removes all comments over all code that is turned in. It's easier to read the code with no comments and if there are no comments the sections that should be commented really pop out (you can then check to see if there are indeed comments in the original file).
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.
Sometimes the comments are valuable, even when every line is commented. A syntax highlighter scheme that had lower contrast for the comments would be a better workaround.
Having been a TA for CS1 classes, I can understand the rationale behind it to some degree. It's ridiculous how many students go online and ask for someone to do their homework or even copy chunks of code off of stack overflow. Forcing them to explain every line is one way of judging how well they actually understand what they're writing (if they do at all). Of course it's going to be annoying to anyone who already has the slightest experience... but what can you do?
For the first programming courses I can understand the commenting, but I've been TA for advanced courses where many of the students have passed the compiler class. They don't need comments anymore, and it really detract from the readability of the code.
