Answers.Body: <p>I would suggest two things. Both of them, however, require that you give them printouts of the code so that they can make notations of their own without having to use any tool. Just write on the paper. Also, I'm assuming that your code is in small pieces, say, short methods. For me, a method is long at about five lines and a method that covers a page is incomprehensible. I have anecdotal evidence from industry that the latter is also true. </p>
  
  <p>One method, assuming that you have given students the code is to just project it from your normal IDE and highlight it with the mouse. Ask the students about it and talk about it. Asking is probably more effective. You don't need to write anything. </p>
  
  <p>Another uses a tool like Powerpoint. Build a deck in which each page shows exactly the same code but with different sections highlighted as you desire, using one or more colors. You can flip between pages as you talk, flipping both forward and backward as needed. But, again, ask the students to explain, rather than giving your own explanations. This way you can pick up misconceptions they might have and correct them. Make sure that the code itself has the same alignment on each page. Then when you flip, only the highlighting changes and students don't need to readjust the context. </p>
  
  <p>Perhaps you can project against a writable surface rather than a screen. If you project on a whiteboard (and can ignore the glare) you can use marker pens to annotate - especially when the students say the right thing. </p>
  
  <p>Make it interactive. Broadcast is much less effective. </p>
  
  <p>Also, since you are putting effort in anyway, make sure that you <em>always</em> use <em>intention revealing names</em> in your demo code. Don't use x, y, z, i, j, k. Make the names come from the problem being solved, not the solution. For example <em>counter</em> is a name from the solution. But negative_value_counter is a name from the problem (of counting negative values - duh). In this way, if you are primarily teaching them about how to structure programs, you can focus on the structure (if, while, ...) rather than having them wonder about the purpose of abstract names. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-22T20:39:57.133Z
Answers.LastActivityDate: 2018-12-22T20:47:40.763Z
Answers.LastEditDate: 2018-12-22T20:47:40.763Z
Answers.UserDisplayName: Buffy
Answers.Body: <p>You need to know about <a href="http://pythontutor.com/" rel="nofollow noreferrer">http://pythontutor.com/</a> - they have line-by-line execution and a diagram showing memory and how it changes. They also have more than just Python, they have Java,  C,  C++,  JavaScript, &amp; Ruby</p>
  
  <p>I have used this resource in my classes and it makes it <em>so amazing</em> to explain how memory, references, and classes work. The C tutor really helps with pointers as well.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-28T19:06:15.830Z
Answers.Text: Welcome to [cseducators.se]! Nice first contribution, and I hope we see more of you around :). Once you have the rep, feel free to visit the chat room and introduce yourself. (It's been slower going in the chatroom lately, but there's almost always one of the site regulars around, and you can type @ and any recently posting user (such as `@buffy`, `@gypsyspellweaver`, or `@beni`) to ping them and get a greeting :)
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-28T18:01:58.297Z
Answers.LastActivityDate: 2018-12-28T18:01:58.297Z
Answers.UserDisplayName: Liz H
Answers.Body: <p>I create code-comprehension sheets outlined in one of two ways (depending on the code): code on the left, with questions on the right, or code with questions interspersed like comments.</p>
  
  <p>There are a few uses for such sheets:</p>
  
  <ol>
  <li>Check comprehension of what we've just gone over.</li>
  <li>Force students to try to examine and digest code <em>prior</em> to going over it together (to increase interest/retention when we go over the material.)</li>
  <li>Assessments.</li>
  </ol>
  
  <p>Typically I will do this with 1-3 pages of code that has to be understood on several different levels in order to make sense of it.  Think objects, or assembly code.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-22T23:51:29.117Z
Answers.LastActivityDate: 2018-12-22T23:51:29.117Z
Answers.UserDisplayName: Ben I.
Answers.Body: <p>I'm taking a very basic approach when I do it: I use my Editor and comment line by line. This way I can directly show alternatives and effects if something does not work as planned. 
  Usually I'm developing the code live to avoid that students get distracted by the code to come. 
  The good thing about this approach is, you can show them how you can develop a program from scratch and how you are digging into the finer aspects of problem solving. E.g. you can "forget" one condition in a loop and create an endless loop - and show them how you can find the mistake. </p>
  
  <p>Another thing I did which comes closer to your UML example: I'm using a surface tablet in my class and sometimes I'm just taking a quick screenshot and use the pen to write on this screenshot. This works nicely and does not need additional tools (once you are having a tablet with pen).</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-22T19:55:53.043Z
Answers.Text: I disagree about line by line comments. It is, in particular, a terrible coding practice. If the code doesn't speak for itself it is broken. If the comments and code don't agree, they are probably both wrong. If you do this as an active practice when demonstrating, I fear that the students will want to take it up themselves. In professional circles using high level languages (not assembler) inline comments are considered to be a _code smell_. Don't encourage it. The solution is  (a) better names and (b) shorter functions/methods. Then all you need to comment is the intent using, say, javadoc.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-22T19:59:39.363Z
Answers.Text: @Buffy I agree if the students are a bit more advanced. But for beginners it is helpful to explain basic concepts again. E.g. "why is this a pointer" or "why do I have to check for a certain condition".
  Of course, speaking names are a must!
Answers.UserDisplayName: OBu
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-22T20:03:50.267Z
Answers.Text: You can do that without inline comments. Don't teach them to do things that you don't want them to do themselves. A hand written comment on an overlay isn't the same thing as an inline comment. "But _teacher_ does it. Why shouldn't I?"
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-22T20:05:10.997Z
Answers.Text: Or use pair learning and have one student explain verbally the code of another as it is being written.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-22T20:13:33.127Z
Answers.Text: Always  try to organize your teaching so that you never have to unteach anything. Don't lead them to bad habits of work or thought that you will have to tell them later not to do that. You can be incomplete in explanations, metaphors, etc, but don't take them down the wrong path thinking that you will show them the better path later. It is a bit harder to always consider that, but necessary IMO
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-22T19:49:58.670Z
Answers.LastActivityDate: 2018-12-22T19:49:58.670Z
Answers.UserDisplayName: OBu
Body: <p>I am thinking about "dissecting" my code with students, going line by line and commenting (why is this the condition of the while? What does this piece of code do?)</p>
  
  <p>A simple example can be found here: <a href="https://docs.google.com/document/d/1mxTE_E2_YKq-yhaXAfBxYP11uaRm7bSXTnP55bMnPyQ/edit" rel="noreferrer">https://docs.google.com/document/d/1mxTE_E2_YKq-yhaXAfBxYP11uaRm7bSXTnP55bMnPyQ/edit</a></p>
  
  <p>However, I would like a better tool for the job. As you can see, in docs, the comments are far away from the code and not linked to their respective by any visual cue. They are also all on the same color. </p>
  
  <p>I tryed some highlighting tools for docs, but they seem to just highlight,not add colored comments</p>
  
  <p>I am looking for ideas, inside or outside google docs, to do the job.</p>
  
  <p>For inspiration (no way am I ever doing something this pretty!) here is an image from a headfirst book</p>
  
  <p><a href="https://i.sstatic.net/H7riz.png" rel="noreferrer"><img src="https://i.sstatic.net/H7riz.png" alt="Head first diagram"></a></p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-12-23T00:43:08.590Z
Comments.Text: How do you intend to use the output from the "tool"? Is the objective to use it in a visual interactive presentation (such as projected during a lecture), or in a static context to which the students have current and future access (such as shared docs in Google Docs), or even a printout handed to the students prior to or during the presentation?
Comments.UserDisplayName: Gypsy Spellweaver
Tags: <lecture-tools>
Title: Code highlight for classroom use
ThreadText: # Code highlight for classroom use
  
  (Asked by: username_0 on 2018-12-22)
  
  I am thinking about "dissecting" my code with students, going line by line and commenting (why is this the condition of the while? What does this piece of code do?)
  
  A simple example can be found here: <https://docs.google.com/document/d/1mxTE_E2_YKq-yhaXAfBxYP11uaRm7bSXTnP55bMnPyQ/edit>
  
  However, I would like a better tool for the job. As you can see, in docs, the comments are far away from the code and not linked to their respective by any visual cue. They are also all on the same color.
  
  I tryed some highlighting tools for docs, but they seem to just highlight,not add colored comments
  
  I am looking for ideas, inside or outside google docs, to do the job.
  
  For inspiration (no way am I ever doing something this pretty!) here is an image from a headfirst book
  
  [![Head first diagram](https://i.sstatic.net/H7riz.png)](https://i.sstatic.net/H7riz.png)
  
  **Tags:** lecture-tools
  
  > **Comments:**
  > **username_1**: How do you intend to use the output from the "tool"? Is the objective to use it in a visual interactive presentation (such as projected during a lecture), or in a static context to which the students have current and future access (such as shared docs in Google Docs), or even a printout handed to the students prior to or during the presentation?  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_2 on 2018-12-22. Score: 5
  
  I would suggest two things. Both of them, however, require that you give them printouts of the code so that they can make notations of their own without having to use any tool. Just write on the paper. Also, I'm assuming that your code is in small pieces, say, short methods. For me, a method is long at about five lines and a method that covers a page is incomprehensible. I have anecdotal evidence from industry that the latter is also true.
  
  One method, assuming that you have given students the code is to just project it from your normal IDE and highlight it with the mouse. Ask the students about it and talk about it. Asking is probably more effective. You don't need to write anything.
  
  Another uses a tool like Powerpoint. Build a deck in which each page shows exactly the same code but with different sections highlighted as you desire, using one or more colors. You can flip between pages as you talk, flipping both forward and backward as needed. But, again, ask the students to explain, rather than giving your own explanations. This way you can pick up misconceptions they might have and correct them. Make sure that the code itself has the same alignment on each page. Then when you flip, only the highlighting changes and students don't need to readjust the context.
  
  Perhaps you can project against a writable surface rather than a screen. If you project on a whiteboard (and can ignore the glare) you can use marker pens to annotate - especially when the students say the right thing.
  
  Make it interactive. Broadcast is much less effective.
  
  Also, since you are putting effort in anyway, make sure that you *always* use *intention revealing names* in your demo code. Don't use x, y, z, i, j, k. Make the names come from the problem being solved, not the solution. For example *counter* is a name from the solution. But negative\_value\_counter is a name from the problem (of counting negative values - duh). In this way, if you are primarily teaching them about how to structure programs, you can focus on the structure (if, while, ...) rather than having them wonder about the purpose of abstract names.
  
  
  ---
  
  ### Answer by username_3 on 2018-12-28. Score: 4
  
  You need to know about <http://pythontutor.com/> - they have line-by-line execution and a diagram showing memory and how it changes. They also have more than just Python, they have Java, C, C++, JavaScript, & Ruby
  
  I have used this resource in my classes and it makes it *so amazing* to explain how memory, references, and classes work. The C tutor really helps with pointers as well.
  
  > **Comments:**
  > **username_4**: Welcome to [cseducators.se]! Nice first contribution, and I hope we see more of you around :). Once you have the rep, feel free to visit the chat room and introduce yourself. (It's been slower going in the chatroom lately, but there's almost always one of the site regulars around, and you can type @ and any recently posting user (such as `@username_2`, `@username_1`, or `@beni`) to ping them and get a greeting :)  
  
  ---
  
  ### Answer by username_5 on 2018-12-22. Score: 4
  
  I'm taking a very basic approach when I do it: I use my Editor and comment line by line. This way I can directly show alternatives and effects if something does not work as planned.
  Usually I'm developing the code live to avoid that students get distracted by the code to come.
  The good thing about this approach is, you can show them how you can develop a program from scratch and how you are digging into the finer aspects of problem solving. E.g. you can "forget" one condition in a loop and create an endless loop - and show them how you can find the mistake.
  
  Another thing I did which comes closer to your UML example: I'm using a surface tablet in my class and sometimes I'm just taking a quick screenshot and use the pen to write on this screenshot. This works nicely and does not need additional tools (once you are having a tablet with pen).
  
  > **Comments:**
  > **username_2**: I disagree about line by line comments. It is, in particular, a terrible coding practice. If the code doesn't speak for itself it is broken. If the comments and code don't agree, they are probably both wrong. If you do this as an active practice when demonstrating, I fear that the students will want to take it up themselves. In professional circles using high level languages (not assembler) inline comments are considered to be a _code smell_. Don't encourage it. The solution is  (a) better names and (b) shorter functions/methods. Then all you need to comment is the intent using, say, javadoc.  
  > **username_5**: @username_2 I agree if the students are a bit more advanced. But for beginners it is helpful to explain basic concepts again. E.g. "why is this a pointer" or "why do I have to check for a certain condition". Of course, speaking names are a must!  
  > **username_2**: You can do that without inline comments. Don't teach them to do things that you don't want them to do themselves. A hand written comment on an overlay isn't the same thing as an inline comment. "But _teacher_ does it. Why shouldn't I?"  
  > **username_2**: Or use pair learning and have one student explain verbally the code of another as it is being written.  
  > **username_2**: Always  try to organize your teaching so that you never have to unteach anything. Don't lead them to bad habits of work or thought that you will have to tell them later not to do that. You can be incomplete in explanations, metaphors, etc, but don't take them down the wrong path thinking that you will show them the better path later. It is a bit harder to always consider that, but necessary IMO  
  
  ---
  
  ### Answer by username_4 on 2018-12-22. Score: 3
  
  I create code-comprehension sheets outlined in one of two ways (depending on the code): code on the left, with questions on the right, or code with questions interspersed like comments.
  
  There are a few uses for such sheets:
  
  1. Check comprehension of what we've just gone over.
  2. Force students to try to examine and digest code *prior* to going over it together (to increase interest/retention when we go over the material.)
  3. Assessments.
  
  Typically I will do this with 1-3 pages of code that has to be understood on several different levels in order to make sense of it. Think objects, or assembly code.
  
  
  ---
  
  