Overview

Formatting

1. Capitalization

Across slides, script, and exercises (context, instructions, hints, sample, and solution code), use proper capitalization of statements and functions in accordance with the SQL standard guidelines. Specifically, this means:

  • Capitalize all standard SQL statements (SELECT , FROM , WHERE , GROUP BY , ORDER  BY , HAVING , etc.).
  • Capitalize all functions in SQL (i.e., SUM() , COUNT(), AVG() ), except where the database-specific documentation indicates that you should not.
  • When adhering to a database-specific set of capitalization guidelines that deviates from SQL standard, tell your students that you are doing this, why you are doing this, and link to the documentation for that platform. For example, PostgreSQL aggregate functions are written in lower case. If you follow this guideline in your slides and exercises, mention it in your slides and exercise context, providing students with a link to the documentation.

2. Consistency in the placement of commas

Across slides, script, and exercises (context, instructions, hints, sample, and solution code), consistently place your commas at the beginning, or the end of each column selected.

  • We are aware that it’s considered acceptable to begin or end your SQL queries with commas. Examples below:

At DataCamp, we consider the first approach (commas at the end of the column selected), to be our standard. We will accept the use of the second approach in the following cases:

  • The course is not an introductory level course.
  • You explain to students at the beginning of the course that you will use this approach, and why.
  • You include a space after the comma, as shown above.
  • You use this approach consistently throughout slides, script, and exercises.

3. Indenting

Across slides and exercises, we require you to properly tab indent the components of your query according to the SQL standard guidelines. On our platform, this equates to 4 spaces. This includes indenting:

  • Columns and tables selected
  • Subqueries/nested subqueries
  • CASE statements

4. Separating Components of your Query

In slides and exercises, it’s important to properly space your exercises according to the SQL standard guidelines so students can view them in the editor. Please consider the following:

  • If selecting more than three columns from a table, or are including more than one complex selection (i.e., AVG(column) or CASE statements), include each column selected on a separate line.
  • If selecting more than one table, include them on separate lines.
  • If filtering in WHERE/HAVING with more than one condition, include them on separate lines.
  • If any line of code crosses the vertical line in the exercise editing screen, which represents approximately 60 characters, separate it into multiple lines. See below:
  • If any line of code (i.e., a long CASE statement) spills onto a second line in the Exercise Preview (even if it’s less than 60 characters), break it into two lines and properly indent it. When viewing this, please keep in mind that we optimize for a 13-inch laptop screen. See below:

5. GROUP BY and ORDER BY column names (not numbers)

We require SQL courses to group and order your queries by the specified column names/aliases rather than by a number. In select instances, such as advanced courses/case studies, we will allow this under specific conditions:

  • Confirm with your curriculum lead/content developer that this is appropriate and does not detract from students focusing on other topics.
  • Tell your students at the beginning of the relevant lesson/exercise that you will be taking this approach, and why.
  • Remind students of the potential downsides of using this approach (i.e., incorrect grouping/ordering).

6. Aliasing

  • For consistency, we require all columns, tables, subqueries, calculations, etc. that use aliases identify those aliases using AS. Please do not exclude AS when aliasing.
Did this answer your question?