Since DataCamp instructors are expected to be experts in their field, we expect instructors to provide the best/most efficient code for a given use case. That said, you must follow certain guidelines, specifically, style guidelines for your given programming language, and DataCamp style and content guidelines to ensure your exercises are consistent with other DataCamp courses and are optimized for DataCamp's platform.
Language style guidelines:
Python: PEP 8
Shell: Shell Style Guide
C++ (for rcpp): Google C++ Style Guide
DataCamp's content guidelines limit you to 15 lines of code per exercise. It's also a good idea to keep lines of code under 60 characters, so the code displays nicely on smaller laptops and tablets. Follow DataCamp's style guidelines to find out how to format code comments.
Good ideas
Write the solution code first.
It is typically easier to write the solution code then delete portions to create the sample code (rather than writing the sample code first then completing it to create the solution).
Match scaffolding to instructions.
Usually, there should be one code comment per instruction.
Use human-readable variable names.
Clarity is more important than brevity. Descriptive variable names are the easiest way to make the code more human-readable.
Common problems and their solutions
Too many possible solutions. If there are lots of possible solutions to a problem, it can become difficult to test that the student got the correct answer. In that case, you may need to provide explicit instructions to the students on how to solve the exercise or provide additional code scaffolding to encourage the students in a particular direction. Ask your Content Developer for advice.
Too much scaffolding. It may be tempting to provide a lot of scaffolding in the sample code to make an exercise easier. This is may be acceptable for beginner courses, or where a lot of code is unavoidable. However, excessive scaffolding risks turning the exercise into a simple "fill-in-the-blanks" situation that discourages the students from bothering to understand the code as a whole.
Overwriting variables. If you overwrite the values of a variable in an exercise, and a student runs the code several times, it has the potential to break that exercise. Try to give unique names to assigned variables.