How to approach students who submit their work which consists of frowned upon tools?

Question

This semester my students had to submit a project. Small, yet rich in functionality console application written in C++. They had 8 weeks during which I was always available for consultations. In addition to that, I have scheduled some extra time for students to consult their ideas, implementation and ponder over some of their problems.

Majority of the submitted projects were of a quite high quality. However, some of them used tools that were neither covered nor are particularly advised by the external sources. On the contrary, actually.

For example, one of the students (out of ~1000) used a bunch of gotos. We are teaching Modern C++ and we have never covered gotos during the laboratories. They were briefly mentioned during lectures, but it was more of a "we don't do that here" comment.

Another submitted project was covered with #regions. As far as I am aware, even in C# it's no longer a practice.

During the course we have frequently commented on the importance of code quality, not merely the solution being functional. During the defense of the project I took my time explaining why such approaches are undesirable, but I was not convinced about the course of action regarding the grade. A part of the grade was being dedicated to code quality and usage of proper tools. The students knew it the whole time. While I could see some negative points being assigned for using goto since it was mentioned in the lectures that students should not use that unless there really is no better way of achieving the desired goal, I am really unsure what to do about #regions or other obscure approaches that do not apply to C++.

Are there preferred way to approach problems like this?

Answer 1

My recommendation is that, for purposes of grading, that you take no action at all. You haven't indicated that you were clear with the students that such "outside the box" tools were not to be used, so it would be changing the rules after the game is played to deduct points now.

The grading rubric used by graders needs to be clear and specific. It needs to be developed along with the exercise prior to giving he assignment, not after it has been completed by students. It doesn't need to be revealed to students, but the instruction given to students needs to be completely consistent with it. If this was not anticipated, then you are ethically a bit stuck. Treat it as a learning exercise for the next time you give a programming exercise. If this is important for grading then make it equally important for instruction.

However, there is the possibility that the code was found, not written by the students, so you might need to explore that.

It is also possible that a few students in your huge class had previous knowledge and habits about coding that they fell back on. Some students in an "elementary" course know quite a lot about coding, though perhaps not very sophisticated. Someone who had done assembly programming in the past might naturally want to use goto in spite of your admonitions.

You might, however, want to have a conversation with the students to see "why" they coded as they did. It might give you some insight about how things occurred.

Answer 2

My recommendation is just a bit harsher than that softy, Buffy (all of whose advice is very good, by the way).

I will often deduct a few points (not much) to create just enough sting to get students to pay attention to how to improve. How many points are needed depends a lot on the population of students you've got. I've taught in a lot of different environments, and I've found that 1 percentage point can be enough for some kids, while 3 or 5 is more liable to catch the attention of others.

If the mistake is egregious enough, I might even go as high as 10, but, again, the purpose is to catch students attention, not to punish, so it would have to be both a very small assignment (with little impact on their larger grade) and a less grade-conscious population for me to go so high.

I would then put a fairly lengthy note explaining the bad practice, and I'd make sure that the note is prominently referenced next to their grade (e.g. see important note at the end or some such.)

An alternative approach is to make a far larger deduction, but write a note saying to see you for a chance to earn the points back. Whether or not something like this is appropriate depends on your institution and circumstances, so I can't comment. I will say that it can really help students learn, and it's an approach that they often appreciate because it both helps them to grow and is pretty non-punitive.

Answer 3

Let me answer from the perspective of a seasoned software developer.

During the course we have frequently commented on the importance of code quality, not merely the solution being functional.

I suppose you made clear that code quality becomes relevant for the grading, hopefully indicating how much influence that aspect has.

Using features that haven't been covered in your course is not a bad thing in itself. Generally, it shows initiative on the side of the student. But with freedom comes responsibility. So, using "outside-the-course" features can earn bonus as well as malus points.

You mention two different aspects:

• goto statements. As more or less every source about goto statements makes it clear that they should be avoided as much as possible, a student using them should have known that. That's worth a big malus.
• #region / #endregion blocks. The intentions are good, to help some editors with structuring the code. But an internet search should have revealed that #region is not a standard C++ construct, making the code dependant on some specific compiler. I'd just comment on the problems, and not subtract any points.