Thursday, March 11, 2021

What’s Up with Novice Programmers and Comments

Continuing my look at papers from the SIGCSE 2021conference. The papers are available for free for a limited time. Get them while you can. I take a look at Usage of the Java Language by Novices over Time: Implications for Tool and Language Design.

The BlueJ tool for teaching Java has the (opt in) ability to collect data on language usage by the novices who use it. This is a valuable research tool and the authors of this paper have taken a good look at it for a number of research questions. I recommend the paper for more insights but I was particularly struck by one finding. Students, in large numbers, delete the comments that BlueJ inserts in code automatically.

BlueJ adds stub JavaDoc comments (which can be used to generate documentation) into objects that are created. Over 45% of projects analyzed had no JavaDoc comments in them Students had gone out of their way to delete them. Not answered in the paper but I suspect many of the comments were not expanded from the default either.

What is it with students and comments? In my own teaching I often created stub projects with comments as sub-goal labels. In several cases I saw those comments deleted before coding started. In other cases the comments were left completely separate from the code created in ways that suggest they were ignored. I know that students don’t see the value in adding comments to their code. Is that our (educators) fault? I know that most of us try to teach good commenting practice but at the same time the projects we assign are easy enough to understand (usually) without comments. But why ignore comments clearly designed to help students?

What’s going on here? This looks like a great research question to me. I wonder if anyone is looking at it? What do you think?

1 comment:

Bryn Jeffries said...

Perhaps students are accidentally exposed to bad demonstrations of commenting when they learn to code - all those line-by-line explanations of each step are useful to a novice, but a terrible example of commenting in practice.

And good commenting only really shows its value when you work with a complex body of code that is either written by someone else, or that you wrote some time ago. Until you see the value, and only if you expect that value to be realised later on, does the burden of adding comments seem like a good investment. Perhaps engaging with code that will endure, such as in an open source project, is one way to achieve this.