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.

- R: The tidyverse style guide
- Python: PEP 8
- SQL: Holywell's SQL Style guide

#### 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 `–`

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

#### Code comments

Start each comment on a *new* line, not on the same line as the code. It is *not* okay to do this to ensure your code fits our 15 line limit.

*Good*:

`# Calculate the sum of x`

y <- sum(x)

*Bad*:

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

Add a single space after the comment character.

*Good*:

`# Calculate the sum of x`

y <- sum(x)

*Bad*:

`#Calculate the sum of x`

y <- sum(x)

Capitalize the first letter of every comment.

*Good*:

`# Calculate the sum of x`

y <- sum(x)

*Bad*:

`# calculate the sum of x`

y <- sum(x)

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

*Good*:

`# Calculate the sum of x`

y <- sum(x)

*Bad*:

`# 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)

*Bad*:

`# Calculate the sum of x. Assign the result to y`

y <- sum(x)

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

*Good*:

`# Calculate the sum of x`

y <- sum(x)

*Bad*:

`# 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 x

y <- ___(___)

@solution_code

# Calculate the sum of x

y <- sum(x)

*Bad*:

`@sample_code`

# Calculate the sum of x

y <- ___(___)

@solution_code

# Use sum() on x

y <- sum(x)

#### 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.

#### Hints

Hints should also be bulleted and always have ending punctuation.