Despite extensive studies from the software engineering community on how naming practices influence programming behavior, the topic receives little attention in education. Prior work indicated little agreement on good naming because it depends on many factors. Students are told that "naming is important'' and "should be meaningful,'' yet its practical implementation is rarely discussed and feedback is lacking. The current work presents a dialogic teaching approach focused on teaching a critical reflection on naming practices through five activity types: (A) perceptions and experiences, (B) create names, (C) evaluate through ranking, (D) compare codes, and (E) locate a mistake. We developed, ran, and analyzed a one-hour workshop, that we present here and share our experiences, leading to recommendations for teachers. Our contribution is twofold: (1) we provide a set of (adaptable) activities and exercises for supporting deliberate naming practices, thereby assisting teachers interested in adopting naming practices into their curriculum; (2) we provide insights regarding the student perspective on naming practices, derived from the activities, revealing potential issues and opportunities in teaching the topic.

Motivation. Many people interested in learning a programming language choose online courses to develop their skills. The concept of variables is one of the most foundational ones to learn, but can be hard to grasp for novices. Variables are researched, but to our knowledge, few empirical observations on how the concept is taught in practice exist. Objective. We investigate how the concept of variables, and the respective naming practices, are taught in introductory Massive Open Online Courses (MOOCs) teaching programming languages. Methods. We gathered qualitative data related to variables and their naming from 17 MOOCs. Collected data include connections to other programming concepts, formal definitions, used analogies, and presented names. Results. We found that variables are often taught in close connection to data types, expressions, and program execution and are often explained using the 'variable as a box' analogy. The latter finding represents a stronger focus on 'storing values', than on naming, memory, and flexibility. Furthermore, MOOCs are inconsistent when teaching naming practices. Conclusions. We recommend teachers and researchers to pay deliberate attention to the definitions and analogies used to explain the concept of variables as well as to naming practices, and in particular to variable name meaning.

Grading large classes has become a challenging and expensive task for many universities. The Delft University of Technology (TU Delft), located in the Netherlands, has observed a large increase in student numbers over the past few years. Given the large growth of the student population, grading all the submissions results in high costs. We made use of self and peer grading in the 2018-2019 edition of our software testing course. Students worked in teams of two, and self and peer graded three assignments in our course. We ended up with 906 self and peer graded submissions, which we compared to 248 submissions that were graded by our TAs. In this paper, we report on the differences we observed between self, peer, and TA grading. Our findings show that: (i) self grades tend to be 8-10% higher than peer grades on average, (ii) peer grades seem to be a good approximator of TA grades; in cases where self and peer grade differ significantly, the TA grade seems to lie in between, and (iii) the gender and the nationality of the student do not seem to affect self and peer grading.

Motivation. Code reading skills are important for comprehension. Explain-in-plain-English tasks (EiPE) are one type of reading exercises that show promising results on the ability of such exercises to differentiate between particular levels of code comprehension. Code reading/explaining skills also correlate with code writing skills. Objective. This paper aims to provide insight in what novice students express in their explanations after reading a piece of code, and what these insights can tell us about how the students comprehend code. Method. We performed an exploratory analysis on four reading assignments extracted from a university-level beginners course in Python programming. We paid specific attention to 1) the core focus of student answers, 2) elements of the code that are often included or omitted, and 3) errors and misconceptions students may present. Results. We found that students prioritize the output that is generated by print-statements in a program. This is indication that these statements may have the ability to aid students make sense of code. Furthermore, students appear to be selective about which elements they find important in their explanation. Assigning variables and asking input was less often included, whereas control-flow elements, print statements and function definitions were more often included. Finally, students were easily confused or distracted by lines of code that seemed to interfere with the newly learned programming constructs. Also domain knowledge (outside of programming) both positively and negatively interfered with reading and interpreting the code. Discussion. Our results pave the way towards a better understanding of how students understand code by reading and of how an exercise containing self-explanations after reading, as a teaching instrument, may be useful to both teachers and students in programming education.