4 ms·

> 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 t

> 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.

kagamine 10y ago
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.
- hvidgaard 10y ago
  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.
  - tamana 10y ago
    In science, there is no such thing as why, there are only deeper levels of what. And those levels are subjective and relative to personal experience. Your comment merits a failing mark, downvotes, because you made the same subjectively wrong statement twice.
    - hvidgaard 10y ago
      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.
hvidgaard 10y ago
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.
vkjv 10y ago
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. Working is the lowest bar of quality.
crispyambulance 10y ago
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.
MustardTiger 10y ago
> It's a little annoying but it doesn't hurt the readability. I find it absolutely destroys readability. It is incredibly hard to follow code written twice.

kagamine 10y ago

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.

hvidgaard 10y ago
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.
- tamana 10y ago
  In science, there is no such thing as why, there are only deeper levels of what. And those levels are subjective and relative to personal experience. Your comment merits a failing mark, downvotes, because you made the same subjectively wrong statement twice.
  - hvidgaard 10y ago
    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.

hvidgaard 10y ago

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.

vkjv 10y ago

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. Working is the lowest bar of quality.

crispyambulance 10y ago

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.

MustardTiger 10y ago

> It's a little annoying but it doesn't hurt the readability. I find it absolutely destroys readability. It is incredibly hard to follow code written twice.