Style Guidelines for Projects

Learn DataCamp's style guidelines, which helps keeps our product clean and consistent across the platform.

Jess Ahmet avatar
Written by Jess Ahmet
Updated over a week ago

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

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.

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)

Did this answer your question?