代做DS2500、代写Python设计程序
- 首页 >> C/C++编程 Spring 2024
Python Grading Guidelines
In DS2500, you’ll have a project, labs, homeworks, and Python Practice Problems (PPPs) that all contribute to your grade. For some of this work, your grade will be entirely based on correctness, and for others your coding/visualization style will play a large role.
Correctness: Labs and PPPs
Labs and PPPs are auto-graded, and you receive full credit if the unit tests in the autograder pass. Make sure you verify the output of the autograder! For these assignments, you will be graded only on the correctness of your code and not on its style.
Correctness + Style: Homeworks and Projects
For projects and homeworks, your code will be reviewed by a DS2500 TA, and your grade will be based in large part on your coding style and visualizations.
Our highest priority is that your code be incredibly clear and easy to work with -- just as the expectation would be in a job or co-op.
In particular, we’ll grade your code based on its readability, modularity, and reusability. We expect your visualizations, including presentation slides, to be easy to follow. You will receive a score of excellent, satisfactory, in progress, or not met on all of these criteria.
Below, you’ll find a grading rubric that we’ll use for every homework and project. Additionally, we’ve included the DS2500 style guide for specific items around spacing, variable names, etc (it’s very similar to the DS2000 style guide!)
Coding + Visualization Grading Rubric
DS2500 Style Guide
Spacing
Variable and Function Names
Strings
Comments
Coding + Visualization Grading Rubric
Category Excellent Good In Progress Not Met
Readability Variable and function names are clear and concise. Code is consistently formatted and makes good use of horizontal and vertical space. No lines exceed 80 characters. All information printed out is readable and uses the appropriate data type and/or rounding. Minor issues with variable naming, formatting, printing, or spacing.
At least one significant issue with readability.
Multiple major issues with readability; code is extremely hard to follow.
Modularity Code is well-organized and split into functions, including a main function to initiate execution. Functions have no more than 30 lines each and are self-contained. Code is not repeated. Control structures (loops, conditionals) are used appropriately within functions. Minor issues with messy or long functions, or with repeated code. At least one significant issue with modularity such as too few functions or disorganized code. Functions not used besides main.
Reusability Code is consistently well-documented and every function has a descriptive block comment. All written code is used in execution. Implementations are efficient. Minor issues with comments, extra/missing code, or inefficiencies. At least one significant issue with reusability. Code could not be reused in another program.
Visualizations Visualizations are clear, easy to follow, and make good use of labels, legends, titles, sizes, and colors. Minor issues with missing tags or confusing/counterintuitive colors. Visualizations chosen are inappropriate for the data, or incorrect based on requirements of the assignment.. Visualizations not present.
DS2500 Style Guide
Spacing
●Group related code together, and use vertical space to separate chunks of code
●Limit your code to 80 columns or less.
●Put white space around operators, and after commas.
Do this (vertical space):
# here is a comment describing the next three lines of code,
# which are all related to each other
Code line 1
Code line 2
Code line 3
# here is a comment describing the next two lines, which are
# separate from the lines above
Code line 4
Code line 5
Do this (horizontal space):
x = y + 5
if x == y:
result = func(18, 19, "hello")
spam = long_function_name(var_one, var_two,
var_three, var_four)
a = 1 + 2 + 3 + 4 \
+ 5 + 6 + 7
Not this:
x=y+5
x=y + 5
x = y+5
if x==y:
Variable and Function Names
●Variable and function names must be short and descriptive.
●Use lowercase letters, and use underscores to separate words. Do not use camel case.
●Constants, whose values never change once initialized, should be uppercase
●Constants can be used/reference in main, but NOT in other functions. To ensure reusability, a function should get all its data via parameters and not assume any constants exist in the file. Constants are defined at the very top of your program, below your comments but above all your functions. All other variables must be local -- i.e., defined within a function.
Do this:
age = 44
birth_year = 1978
first_name = "Laney"
def compute_result()
FILENAME = "file.txt"
Not this:
a = 44
x = 1978
variableName = "Laney"
def FunctionOne()
PI = 3.1415
PI += 4
Strings
●You can use single or double quotes to enclose strings. It doesn’t matter which one, as long as you’re consistent within a program.
●It’s useful to use f-strings for printing variables, especially when you need special formatting (but f-strings are not required for ds2500).
●But, don’t use the % or + operators for printing; they’re old-fashioned!
●Strings are immutable, so we can’t directly modify a string once it’s been created. A string method will generally return a modified copy.
Do this:
print("Hello", name)
print(f"Hello {name}")
Not this:
print("Hello %s" %name)
print("Hello" + name)
Comments
●Before you write any code, put a block comment at the top of every program with your name, the course, the assignment, the date, and the name of the file.
●Comments explaining your code should appear throughout your program.
●Comments go above Python statements, not beside them.
●Put a space between the “#” and the comment.
●Function comments should be a docstring just under the function signature. Apart from this, your functions don’t generally need inline comments unless you’re doing something very complex that requires an explanation.
Do this:
# comment describing my code
python statement
# space after crosshatch
Not this:
python statement # comment describing my code
#no space after crosshatch
Functions should be concise; it’s best to keep them under 30 lines of code. Functions should also accept a limited number of parameters; five of them at the absolute max. Function comments should include the parameters and return type, and they should describe the what of a function as well. You can use bullet points to describe these items, or summarize them.
Do this:
def func(param):
"""
Parameters: a non-negative number
Returns: a float
Does: computes and returns the square root
of the given number
"""
Function code
Function code
def func(param):
"""
Given a non-negative integer, computes
and returns its square root.
"""
Function code
Function code
Not this:
def func(param):
"""
Parameters: a non-negative number
Returns: a float
Does: computes and returns the square root
of the given number
"""
# inline comment
Function code
# inline comment
Function code
Python Grading Guidelines
In DS2500, you’ll have a project, labs, homeworks, and Python Practice Problems (PPPs) that all contribute to your grade. For some of this work, your grade will be entirely based on correctness, and for others your coding/visualization style will play a large role.
Correctness: Labs and PPPs
Labs and PPPs are auto-graded, and you receive full credit if the unit tests in the autograder pass. Make sure you verify the output of the autograder! For these assignments, you will be graded only on the correctness of your code and not on its style.
Correctness + Style: Homeworks and Projects
For projects and homeworks, your code will be reviewed by a DS2500 TA, and your grade will be based in large part on your coding style and visualizations.
Our highest priority is that your code be incredibly clear and easy to work with -- just as the expectation would be in a job or co-op.
In particular, we’ll grade your code based on its readability, modularity, and reusability. We expect your visualizations, including presentation slides, to be easy to follow. You will receive a score of excellent, satisfactory, in progress, or not met on all of these criteria.
Below, you’ll find a grading rubric that we’ll use for every homework and project. Additionally, we’ve included the DS2500 style guide for specific items around spacing, variable names, etc (it’s very similar to the DS2000 style guide!)
Coding + Visualization Grading Rubric
DS2500 Style Guide
Spacing
Variable and Function Names
Strings
Comments
Coding + Visualization Grading Rubric
Category Excellent Good In Progress Not Met
Readability Variable and function names are clear and concise. Code is consistently formatted and makes good use of horizontal and vertical space. No lines exceed 80 characters. All information printed out is readable and uses the appropriate data type and/or rounding. Minor issues with variable naming, formatting, printing, or spacing.
At least one significant issue with readability.
Multiple major issues with readability; code is extremely hard to follow.
Modularity Code is well-organized and split into functions, including a main function to initiate execution. Functions have no more than 30 lines each and are self-contained. Code is not repeated. Control structures (loops, conditionals) are used appropriately within functions. Minor issues with messy or long functions, or with repeated code. At least one significant issue with modularity such as too few functions or disorganized code. Functions not used besides main.
Reusability Code is consistently well-documented and every function has a descriptive block comment. All written code is used in execution. Implementations are efficient. Minor issues with comments, extra/missing code, or inefficiencies. At least one significant issue with reusability. Code could not be reused in another program.
Visualizations Visualizations are clear, easy to follow, and make good use of labels, legends, titles, sizes, and colors. Minor issues with missing tags or confusing/counterintuitive colors. Visualizations chosen are inappropriate for the data, or incorrect based on requirements of the assignment.. Visualizations not present.
DS2500 Style Guide
Spacing
●Group related code together, and use vertical space to separate chunks of code
●Limit your code to 80 columns or less.
●Put white space around operators, and after commas.
Do this (vertical space):
# here is a comment describing the next three lines of code,
# which are all related to each other
Code line 1
Code line 2
Code line 3
# here is a comment describing the next two lines, which are
# separate from the lines above
Code line 4
Code line 5
Do this (horizontal space):
x = y + 5
if x == y:
result = func(18, 19, "hello")
spam = long_function_name(var_one, var_two,
var_three, var_four)
a = 1 + 2 + 3 + 4 \
+ 5 + 6 + 7
Not this:
x=y+5
x=y + 5
x = y+5
if x==y:
Variable and Function Names
●Variable and function names must be short and descriptive.
●Use lowercase letters, and use underscores to separate words. Do not use camel case.
●Constants, whose values never change once initialized, should be uppercase
●Constants can be used/reference in main, but NOT in other functions. To ensure reusability, a function should get all its data via parameters and not assume any constants exist in the file. Constants are defined at the very top of your program, below your comments but above all your functions. All other variables must be local -- i.e., defined within a function.
Do this:
age = 44
birth_year = 1978
first_name = "Laney"
def compute_result()
FILENAME = "file.txt"
Not this:
a = 44
x = 1978
variableName = "Laney"
def FunctionOne()
PI = 3.1415
PI += 4
Strings
●You can use single or double quotes to enclose strings. It doesn’t matter which one, as long as you’re consistent within a program.
●It’s useful to use f-strings for printing variables, especially when you need special formatting (but f-strings are not required for ds2500).
●But, don’t use the % or + operators for printing; they’re old-fashioned!
●Strings are immutable, so we can’t directly modify a string once it’s been created. A string method will generally return a modified copy.
Do this:
print("Hello", name)
print(f"Hello {name}")
Not this:
print("Hello %s" %name)
print("Hello" + name)
Comments
●Before you write any code, put a block comment at the top of every program with your name, the course, the assignment, the date, and the name of the file.
●Comments explaining your code should appear throughout your program.
●Comments go above Python statements, not beside them.
●Put a space between the “#” and the comment.
●Function comments should be a docstring just under the function signature. Apart from this, your functions don’t generally need inline comments unless you’re doing something very complex that requires an explanation.
Do this:
# comment describing my code
python statement
# space after crosshatch
Not this:
python statement # comment describing my code
#no space after crosshatch
Functions should be concise; it’s best to keep them under 30 lines of code. Functions should also accept a limited number of parameters; five of them at the absolute max. Function comments should include the parameters and return type, and they should describe the what of a function as well. You can use bullet points to describe these items, or summarize them.
Do this:
def func(param):
"""
Parameters: a non-negative number
Returns: a float
Does: computes and returns the square root
of the given number
"""
Function code
Function code
def func(param):
"""
Given a non-negative integer, computes
and returns its square root.
"""
Function code
Function code
Not this:
def func(param):
"""
Parameters: a non-negative number
Returns: a float
Does: computes and returns the square root
of the given number
"""
# inline comment
Function code
# inline comment
Function code