You will need to follow DataCamp's style guidelines for your course 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 with, 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.

Grammar

Use American English

Since we are an American company and the USA contains our largest group of students, DataCamp content is written in American English.

Correct: This standardizes the modeling of colors.
Incorrect: This standardises the modelling of colours.

Using American English also means using American punctuation rules.

Commas, periods, and exclamation marks should be placed inside quotation marks when applicable. Ex: “I love DataCamp,” said Michael.
Include a comma after the following abbreviations: i.e., e.g.,

Use full sentences

Learners are going to read the content you create, and you will not be there to clarify what you've written, so make sure to use full, properly punctuated, clear sentences.

Spacing and punctuation

Comma usage

Use the Oxford comma when writing content. The Oxford comma places a comma between the word “and” or “or” and the last item in a list. Because DataCamp content frequently covers complex topics, the Oxford comma can be helpful to clarify the meaning of sentences.

Good: DataCamp has courses in R, Python, SQL, and spreadsheets.
Bad: DataCamp has courses in R, Python, SQL and spreadsheets.

Spacing

There should only be one space following punctuation marks and between sentences.

Good: Calculate the sum. Print the value.
Bad: Calculate the sum. Print the value.

Hyphens

Use hyphens to link all the words in a compound adjective. Do not use a hyphen if the construction includes very or an adverb ending in -ly.

Good: The company makes data-driven decisions.
Bad: The company makes data driven decisions.
Good: The project had quickly diminishing returns.
Bad: The project had quickly-diminishing returns.

Abbreviations

Ampersands

Ampersands should not be used in place of "and."

Good: DataCamp has courses about data science and machine learning.
Bad: DataCamp has courses about data science & machine learning.

Versus, vs.

Always use the full word “versus” in full sentences.

Good: When should I use R versus Python for data analysis?
Bad: When should I use R vs. Python for data analysis?

Always use the lowercase abbreviation “vs.” in chapter, lesson, exercise, and slide titles.

Good: TensorFlow vs. Keras for Deep Learning

Data-related terms

DataFrames, data frames

When using one of these terms, follow the appropriate usage based on the context of coding language.

In the context of Python: DataFrame, DataFrames
In the context of R: data frame, data frames

Dataset

Always write “dataset” as one word.

Correct: The course uses a large dataset.
Incorrect: The course uses a large data set.

Formatting

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.

Use a dot before method/attribute names

Good: Use the .fit() method to fit your model.
Bad: Use the fit() method to fit your model.

Format functions, methods, statements, and package names as inline code

Module and library names should also be formatted this way.

Good: The seaborn package produces pretty plots.
Bad: The seaborn package produces pretty plots.

Packages

Follow the style of the original name of the package, including the original capitalization style. Even at the beginning of a sentence, packages should not be capitalized unless the package name is capitalized.

Good: forcats is an R package for working with categorical data.
Bad: Forcats is an R package for working with categorical data.

Code

Code style

Follow these standard style guides for any code in exercises or code written on slides.

R: The tidyverse style guide
Python: PEP 8
SQL: Holywell's SQL Style guide
Shell: Shell Style Guide
C++ (for rcpp): Google C++ Style Guide

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 and hints

Instructions

Instructions should be bulleted, even if there is only one instruction. All instructions should have ending punctuation, even if the last word is formatted as inline code.

Hints

Hints should also be bulleted and always have ending punctuation.