You will need to follow DataCamp's style guidelines when creating Practice content to ensure a consistent look and feel for our students. While you may have your own preferred style, these style guidelines are what DataCamp students are familiar with.

Make sure to adhere to all of the following:

Use American English

We are an American company, and the USA contains our largest group of students, so all instructions must be written in American English.

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

Prepare the student for the exercise

In the context block, use full, properly punctuated, clear sentences. However, given that our students can also take Practice in our mobile app, the context block should not exceed 200 characters. So keeping it informative & concise, is the message here.

When relevant, use the context block to tell students about relevant packages, datasets, and functions that have been pre-loaded for them in the pre-challenge code. Always show datasets and/or displayed code as the final element of context, after all prose description of the challenge.

When displaying a dataset in the context block, simply echo it from the prompt rather than adding an explicit call.

Good:

courses
                course_title technology
1  Exploratory Data Analysis          R
2  Credit Risk Modeling in R          R
3    Sentiment Analysis in R          R

Bad:

> print(courses)
                course_title technology
1  Exploratory Data Analysis          R
2  Credit Risk Modeling in R          R
3    Sentiment Analysis in R          R

In some cases, it might be more relevant to show a summary of the data set rather than a preview. You should decide on a case-by-case basis what introduction best fits the exercise.

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 object types, modules and libraries this way.

Good: The Python package pandas produces pretty plots. You could have an object called df that is a data frame of type data.frame.
Bad: The Python package pandas produces pretty plots.  You could have an object called "df" that is a data frame of type data.frame.

Code

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

Code output

Remember that our students can also take Practice in our mobile app. That's why the code output should not contain more than 5 lines. The code output also shouldn't be too wide. That's why you should restrict tables to contain no more than 3 columns, and use concise, but informative column names.

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)

Don't use back-ticks 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)

Use double quotes

Use double quotes for string literals rather than single quotes wherever possible in code shown in context or blanks challenges.

Good

date1 <- as.Date(str1, format = "%b %d, %Y")

Bad:

date1 <- as.Date(str1, format = '%b %d, %Y')

Don't use hyperlinks

Hyperlinks don't work in Practice exercises, so just don't include them. That's clear, right?

Did this answer your question?