Answers.Body: <p>We use the Eclipse plugin Checkstyle. The plugin is configured with a set of rules (defaults styles are available with the plugin), and then generates a set of warnings for any violations of these rules. Toward the end of our CS1, we introduce students to the tool (the students have been taught our expectations throughout the semester). After they are introduced to the plugin, all of their remaining projects will lose points if they have Checkstyle warnings in their project submission (e.g., one points off per warning to a max of 10 points). Checkstyle gives them immediate feedback as they are writing code (in the same way compiler warnings/errors are presented in Eclipse) with the loss of points as incentive to not just ignore the warnings. This practice is continued in CS2 from the start of the semester.</p>
  
  <p>This experience is at University level, but should be applicable to anyone using Eclipse in an AP CS A or similar course.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-07T16:24:20.917Z
Answers.LastActivityDate: 2017-06-07T16:24:20.917Z
Answers.UserDisplayName: Jonathan Corley
Answers.Body: <p>I use an online auto grader for probably 95% of the assignments my students - high school, AP-A - do in class. Before that I would run unit tests on the submitted code and then leave comments. But I've found that the immediate feedback, especially on smaller assignments, helps them learn to solve the problems on their own. Plus, it saves me from having to look at 10 or 15 versions of their code. I typically only look at the one that works. </p>
  
  <p>For style, I'll leave comments on completed assignments when it's bad. </p>
  
  <p>What I've found really helps though is to not help them with questions if the code is a mess. Especially early in the year "clean up your code, and I'll come back" is my stock answer if it's messy. After a couple times they'll clean it up on their own, and usually they'll figure out the problem on their own. </p>
  
  <p>I don't have specific rules other than it's easy to follow. Coding styles tend to be pretty subjective - braces on the same line, or the next line; should the brace be indented; should an else be on the same line as the brace closing the if. I tell them it's like handwriting. If it's neat, it's easier to read. </p>
  
  <p>I will show examples, both good and bad, anonymously on the board. Some kids don't understand what a good snippet of code looks like. But almost everyone can agree on messy code. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-07T20:59:52.417Z
Answers.LastActivityDate: 2017-06-07T20:59:52.417Z
Answers.UserDisplayName: Ryan Nutt
Answers.Body: <p>In my high school class, decades ago, all programs had to be submitted to a fellow student of choice for a "peer review" and critique before being submitted to the teacher. People took these reviewing tasks seriously, because the score for the review was the same as the score for the underlying program itself. That tended to improve the coding practices of both parties by aligning their interests.</p>
  
  <p>In the first semester, the highest grade was earned by the person with most reviews. That was true even though he submitted relatively few programs himself. Instead, he had become the "go to" person for reviewing others' work, and his "best practices" permeated the rest of the class.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-11T19:14:09.573Z
Answers.Text: "the score for the review was the same as the score for the underlying program itself" - very interesting idea.  How can you convince someone else to look at your work when there is such a threatening grading policy?
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-11T19:20:28.193Z
Answers.Text: @Ben I.: First of all, the scores were additive, not averaged. So you could get the same cumulative score, 80, for 10 programs or reviews with an average score of 8, or 8 items with all 10s. Even so, there was a time constraint. So this one go-to guy had his pick of the best programmers, etc. He was not the best programmer but the best editor. Essentially the class sorted itself out, with programmers and reviewers finding counterparts of roughly equal caliber, barring "interpersonal" factors (e.g. the three girls in the class mostly reviewed each other's work).
Answers.UserDisplayName: Tom Au
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-11T19:34:25.167Z
Answers.Text: If I get time, I'm going to work up a question about this idea... students reviewing students. Or someone else can ask. That would be a very interesting discussion indeed!
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-11T19:02:01.770Z
Answers.LastActivityDate: 2017-06-11T19:02:01.770Z
Answers.UserDisplayName: Tom Au
Body: <p>From an instructor perspective (Middle School or High School), Is there a method, or a set of guidelines, for grading early coders' projects that could enhance good coding practices as the students advance further into computer science?</p>
  
  <p>Are any "online practice sites" or "auto-graders" worthy enough to look at for daily or lab project/practice?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-07T16:19:44.997Z
Comments.Text: Welcome to CSEducators.SE! Thanks for your first question. It seems like you are asking two questions here: one on guidelines and one on practice sites. Is that correct? If so, I'd suggest splitting this into two separate questions. Also, can you specify the relevant language(s)? Good coding practices and grading guidelines will most likely vary depending on the language.
Comments.UserDisplayName: Peter
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-08T09:26:22.913Z
Comments.Text: This question would be improved if the title was more distinct from the other ta:best-practice question (which I don't feel is really related, so I won't link here). I think you're asking more about implementing style checking flows rather than 'selling' the concept of best practice.
Comments.UserDisplayName: Sean Houlihane
Tags: <grading><best-practice><auto-graders><coding-style>
Title: Suggestions for encouraging good Coding Practices?
ThreadText: # Suggestions for encouraging good Coding Practices?
  
  (Asked by: username_0 on 2017-06-07)
  
  From an instructor perspective (Middle School or High School), Is there a method, or a set of guidelines, for grading early coders' projects that could enhance good coding practices as the students advance further into computer science?
  
  Are any "online practice sites" or "auto-graders" worthy enough to look at for daily or lab project/practice?
  
  **Tags:** grading, best-practice, auto-graders, coding-style
  
  > **Comments:**
  > **username_1**: Welcome to CSEducators.SE! Thanks for your first question. It seems like you are asking two questions here: one on guidelines and one on practice sites. Is that correct? If so, I'd suggest splitting this into two separate questions. Also, can you specify the relevant language(s)? Good coding practices and grading guidelines will most likely vary depending on the language.  
  > **username_2**: This question would be improved if the title was more distinct from the other ta:best-practice question (which I don't feel is really related, so I won't link here). I think you're asking more about implementing style checking flows rather than 'selling' the concept of best practice.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_3 on 2017-06-07. Score: 5
  
  We use the Eclipse plugin Checkstyle. The plugin is configured with a set of rules (defaults styles are available with the plugin), and then generates a set of warnings for any violations of these rules. Toward the end of our CS1, we introduce students to the tool (the students have been taught our expectations throughout the semester). After they are introduced to the plugin, all of their remaining projects will lose points if they have Checkstyle warnings in their project submission (e.g., one points off per warning to a max of 10 points). Checkstyle gives them immediate feedback as they are writing code (in the same way compiler warnings/errors are presented in Eclipse) with the loss of points as incentive to not just ignore the warnings. This practice is continued in CS2 from the start of the semester.
  
  This experience is at University level, but should be applicable to anyone using Eclipse in an AP CS A or similar course.
  
  
  ---
  
  ### Answer by username_4 on 2017-06-07. Score: 2
  
  I use an online auto grader for probably 95% of the assignments my students - high school, AP-A - do in class. Before that I would run unit tests on the submitted code and then leave comments. But I've found that the immediate feedback, especially on smaller assignments, helps them learn to solve the problems on their own. Plus, it saves me from having to look at 10 or 15 versions of their code. I typically only look at the one that works.
  
  For style, I'll leave comments on completed assignments when it's bad.
  
  What I've found really helps though is to not help them with questions if the code is a mess. Especially early in the year "clean up your code, and I'll come back" is my stock answer if it's messy. After a couple times they'll clean it up on their own, and usually they'll figure out the problem on their own.
  
  I don't have specific rules other than it's easy to follow. Coding styles tend to be pretty subjective - braces on the same line, or the next line; should the brace be indented; should an else be on the same line as the brace closing the if. I tell them it's like handwriting. If it's neat, it's easier to read.
  
  I will show examples, both good and bad, anonymously on the board. Some kids don't understand what a good snippet of code looks like. But almost everyone can agree on messy code.
  
  
  ---
  
  ### Answer by username_5 on 2017-06-11. Score: 1
  
  In my high school class, decades ago, all programs had to be submitted to a fellow student of choice for a "peer review" and critique before being submitted to the teacher. People took these reviewing tasks seriously, because the score for the review was the same as the score for the underlying program itself. That tended to improve the coding practices of both parties by aligning their interests.
  
  In the first semester, the highest grade was earned by the person with most reviews. That was true even though he submitted relatively few programs himself. Instead, he had become the "go to" person for reviewing others' work, and his "best practices" permeated the rest of the class.
  
  > **Comments:**
  > **username_6**: "the score for the review was the same as the score for the underlying program itself" - very interesting idea.  How can you convince someone else to look at your work when there is such a threatening grading policy?  
  > **username_5**: @username_6.: First of all, the scores were additive, not averaged. So you could get the same cumulative score, 80, for 10 programs or reviews with an average score of 8, or 8 items with all 10s. Even so, there was a time constraint. So this one go-to guy had his pick of the best programmers, etc. He was not the best programmer but the best editor. Essentially the class sorted itself out, with programmers and reviewers finding counterparts of roughly equal caliber, barring "interpersonal" factors (e.g. the three girls in the class mostly reviewed each other's work).  
  > **username_6**: If I get time, I'm going to work up a question about this idea... students reviewing students. Or someone else can ask. That would be a very interesting discussion indeed!  
  
  ---
  
  