Best Practices of Code Organization
06-10-2017
, 08:21 AM
Regarding the merging.
You could divide the class in groups or establish some kind of hierarchy
Each student will do their own code but also share with each other and talk what works and what doesn't and perhaps come with a draft then each will code and try different things and then they merge. Now they have turtle_race vs 1 and everyone would continue to develop that.
Finally those drafts from groups would be looked at and merged or which level of merging works for you.
Watched some talks regarding LINUX development and how open source community works/ people take from each other ideas and what works. Like Linus says everyone trusts really a few people and they trusts some folks he would listen and they trust some others who they would take code from etc,. Linux community as I understand have a strict rules of coding practice.
I agree that it is good that you try to explain them what good code looks like but since you are not expecting them to move to software development I would say it is as important that what ever the rules are(may not be the best ones) that they are followed.
There are good coding practises but it is important as well what is good coding practise for your group.
If you want to merge perhaps make sure that code is kept simple and one function does one thing and does it well and functions more or less independently where possible of other functions on their code. That way it is easier to merge.
Others in this forum who actually work on software development and see daily how tens/hundreds of developers work on their code and merge may have some good ideas.
I wouldn't try to merge from 50 code samples, let them collaborate and find what works and you would be more of a maintainer. Collaborating with others would be good lesson from them as well rather than people just working on their code and there would be constant merging rather than one just at the end and what people/groups think are the best ideas /best 'code' resulting to the best end product (or end product the group thinks is best). Obviously it depends what is the final task and complexity and if you want to grade each individuals work.
You could have a clear goal for them. For example they are developing a game and idea is to make it work without bugs and be entertaining with a lot of options so they have an idea what they should aim for and meet the expectations without giving too strict guidelines (no need to go for longs list of user requirements
You could divide the class in groups or establish some kind of hierarchy
Each student will do their own code but also share with each other and talk what works and what doesn't and perhaps come with a draft then each will code and try different things and then they merge. Now they have turtle_race vs 1 and everyone would continue to develop that.
Finally those drafts from groups would be looked at and merged or which level of merging works for you.
Watched some talks regarding LINUX development and how open source community works/ people take from each other ideas and what works. Like Linus says everyone trusts really a few people and they trusts some folks he would listen and they trust some others who they would take code from etc,. Linux community as I understand have a strict rules of coding practice.
I agree that it is good that you try to explain them what good code looks like but since you are not expecting them to move to software development I would say it is as important that what ever the rules are(may not be the best ones) that they are followed.
There are good coding practises but it is important as well what is good coding practise for your group.
If you want to merge perhaps make sure that code is kept simple and one function does one thing and does it well and functions more or less independently where possible of other functions on their code. That way it is easier to merge.
Others in this forum who actually work on software development and see daily how tens/hundreds of developers work on their code and merge may have some good ideas.
I wouldn't try to merge from 50 code samples, let them collaborate and find what works and you would be more of a maintainer. Collaborating with others would be good lesson from them as well rather than people just working on their code and there would be constant merging rather than one just at the end and what people/groups think are the best ideas /best 'code' resulting to the best end product (or end product the group thinks is best). Obviously it depends what is the final task and complexity and if you want to grade each individuals work.
You could have a clear goal for them. For example they are developing a game and idea is to make it work without bugs and be entertaining with a lot of options so they have an idea what they should aim for and meet the expectations without giving too strict guidelines (no need to go for longs list of user requirements
Last edited by vento; 06-10-2017 at 08:50 AM.
06-10-2017
, 12:11 PM
Quote:
Regarding the merging.
You could divide the class in groups or establish some kind of hierarchy
Each student will do their own code but also share with each other and talk what works and what doesn't and perhaps come with a draft then each will code and try different things and then they merge. Now they have turtle_race vs 1 and everyone would continue to develop that.
You could divide the class in groups or establish some kind of hierarchy
Each student will do their own code but also share with each other and talk what works and what doesn't and perhaps come with a draft then each will code and try different things and then they merge. Now they have turtle_race vs 1 and everyone would continue to develop that.
Quote:
If you want to merge perhaps make sure that code is kept simple and one function does one thing and does it well and functions more or less independently where possible of other functions on their code. That way it is easier to merge.
Code:
def draw_track():
track = turtle.Turtle()
track.hideturtle()
track.pensize(3)
track.speed(0)
track.penup()
track.goto(-250,-100)
track.pendown()
track.goto(250,-100)
track.goto(250,-50)
track.goto(-250,-50)
track.goto(-250,0)
track.goto(250,0)
track.goto(250,50)
track.goto(-250,50)
track.goto(-250,100)
track.goto(250,100)
track.goto(250,-100)
track.goto(-250,-100)
track.goto(-250,100)
track.penup()
track.goto(0,150)
track.write('Turtle Race!', font=("Arial", 14, "normal"), align='center')
import random
import turtle
import time
screen = turtle.Screen()
draw_track()
P1 = turtle.Turtle()
P1.penup()
P1.shape('turtle')
P1.color('red')
P1.speed(0)
P1.goto(-268,75)
P2 = turtle.Turtle()
P2.penup()
P2.shape('turtle')
P2.color('blue')
P2.speed(0)
P2.goto(-268,25)
P3 = turtle.Turtle()
P3.penup()
P3.shape('turtle')
P3.color('orange')
P3.speed(0)
P3.goto(-268,-25)
P4 = turtle.Turtle()
P4.penup()
P4.shape('turtle')
P4.color('purple')
P4.speed(0)
P4.goto(-268,-75)
done = 0
P1x = -268
P2x = -268
P3x = -268
P4x = -268
track.goto(0,125)
track.write('Ready... ', font=("Arial", 14, "normal"), align='center')
time.sleep(random.randint(2,5))
track.write(' GO!', font=("Arial", 14, "normal"), align='center')
while done == 0:
P1x = P1x + random.randint(3,10)
P2x = P2x + random.randint(3,10)
P3x = P3x + random.randint(3,10)
P4x = P4x + random.randint(3,10)
P1.setx(P1x)
P2.setx(P2x)
P3.setx(P3x)
P4.setx(P4x)
if P1x >= 232 or P2x >= 232 or P3x >= 232 or P4x >= 232:
done = 1
But as students introduce different things (variables to track the wagering, maybe some information that randomizes turtle racing characteristics so that it's not always a fair race), I'm having problem anticipating how this would be brought together.
Quote:
I wouldn't try to merge from 50 code samples, let them collaborate and find what works and you would be more of a maintainer.
Quote:
Collaborating with others would be good lesson from them as well rather than people just working on their code and there would be constant merging rather than one just at the end and what people/groups think are the best ideas /best 'code' resulting to the best end product (or end product the group thinks is best). Obviously it depends what is the final task and complexity and if you want to grade each individuals work.
I'm setting up the class so that in the first few weeks there will be "Find your own tutorials on the internet" for doing some basic things after I've set them up ("Find your own turtle tutorial" is one of them). I'm wanting them to then share their tutorials with each other and see all of the differences in code/coding styles and then figure out how to make them work together.
For example, I've primed them for this sort of thing by giving them two codes. One starts with
Code:
import turtle screen = turtle.Screen()
Code:
from turtle import * screen = Screen()
Quote:
You could have a clear goal for them. For example they are developing a game and idea is to make it work without bugs and be entertaining with a lot of options so they have an idea what they should aim for and meet the expectations without giving too strict guidelines (no need to go for longs list of user requirements
