You will need to follow DataCamp's style guidelines for your project to help create a consistent look and feel for students. While you may have your own preferred style, these style guidelines are what DataCamp students are familiar, and your style may not be understood if it's not clear when you are referring to specific pieces of the code. Make sure to adhere to all of the following in your course/project:

### Use American English

We are an American company, and the USA contains our largest group of students, so all courses/projects must be written in American English. It is up to you to ensure this.

Good: This standardizes the modeling of colors.
Bad: This standardises the modelling of colours.

### Use full sentences

Students are going to read the contents of your course/project; you need to make sure to use full, properly punctuated, clear sentences. Remember that you will not be there to explain things to students, so listing things you think students will understand is not going to be enough.

### Use parentheses after function/method names

This formatting helps distinguish functions and methods from variable names.

Good: Call the `mean()` function.
Bad: Call the `mean` function.

### Format package names as inline code

Also, format modules and libraries this way.

Good: The Python package `pandas` produces pretty plots.
Bad: The Python package pandas produces pretty plots.

### Code

Follow these standard style guides, unless you have a really good reason not to.

### Use en-dashes for numeric ranges

Separate the lower and upper limits of numeric or date ranges with an en-dash. You can type these in markdown using `&ndash;` .

Good: Filter for ages in the 18–60 range.
Bad: Filter for ages in the 18-60 range.

Start each comment on a new line, not on the same line as the code.

Good:

``# Calculate the sum of xy <- sum(x)``

``y <- sum(x) # Calculate the sum of x``

Add a single space after the comment character.

Good:

``# Calculate the sum of xy <- sum(x)``

``#Calculate the sum of xy <- sum(x)``

Capitalize the first letter of every comment.

Good:

``# Calculate the sum of xy <- sum(x)``

``# calculate the sum of xy <- sum(x)``

If you have one sentence, don't use ending punctuation.

Good:

``# Calculate the sum of xy <- sum(x)``

``# Calculate the sum of x.y <- sum(x)``

If you have multiple sentences in your comment, end each with a period. However, keep comment length short (< 60 characters).

Good:

``# Calculate the sum of x. Assign the result to y.y <- sum(x)``

``# Calculate the sum of x.  Assign the result to yy <- sum(x)``

Don't use backticks or quotes to refer to variables or functions inside comments.

Good:

``# Calculate the sum of xy <- sum(x)``

``# Calculate the sum of `x`y <- sum(x)``

Code comments must be identical for sample code and solution code.

Good:

``@sample_code# Calculate the sum of xy <- ___(___)@solution_code# Calculate the sum of xy <- sum(x)``

``@sample_code# Calculate the sum of xy <- ___(___)@solution_code# Use sum() on xy <- sum(x)``

### Context

The most common error instructors make in `@context` cells is referring to the student or the project. We want project notebooks to appear as a blog post or a data analysis.

Bad: In this project, you will...

Good: In this notebook, we will...

Save the instruction for the `@instructions`, `@hint`, and `@tests` cells, where you can refer to the student and the project.

### Instructions

All instructions should have ending punctuation. Even if the last word is formatted inline code.

The "Helpful links:" bullets should not be full sentences and should not have ending punctuation.

Unlike the context, you can refer to the student and the project in the instructions.

Good: To complete this project, your two questions are as follows:
Bad: To complete this notebook, our two questions are as follows:

### Hints

Hints should also be bulleted and always have ending punctuation. You can also refer to the student and the project in the hints.