Racket Basics and Style
Last updated: Mon, 9 Mar 2026 12:55:54 -0400
This page gives a basic introduction to the Racket programming language.
Note that this course uses "racket450", which is a version of Racket tailored for this course.
Nonetheless, the Racket documentation and the Textbook include many more details and will be useful resources this semester.
1 Installation
See Racket’s "Getting Started Page"
2 Programming Basics
All Racket files end with a .rkt extension, e.g., hw0.rkt.
Every hw solution file (in this class) must begin with #lang racket450 as the first line.
This specifies that the code that follows is written in the racket450 language.
In addition, hw test files (in this class) must begin with #lang racket450/testing as the first line.
This will allow you to use special convenient testing forms designed for this class.
Identifiers in Racket can use more characters than other languages typically allow. (Also, they are case sensitive!)
Some non-traditional characters commonly used in Racket identifiers are -, ?, !, and /.
See this page for a complete list of allowed/disallowed characters in an identifier.
Comment lines begin with a semicolon (;) (see commenting style in the next section).
Alternatively, s-expressions may be commented with a "hash-semicolon" (#;).
3 Racket Style
Code is read much more often than it is written (well over 10 to 1). Thus readability is one of the most important aspects of code.
To be most readable, however, all code must be written according to some accepted list of style guidelines.
In this course, we will use the Racket Style Guide.
Here are a few conventions that we’ll use more frequently:
Spacing: Closing parentheses do not go on their own line.
Spacing: Indentation matters. When in doubt, use DrRacket’s auto-formatter.
Code Organization: provides and requires go at the top of the file (provides first).
Brackets have the same meaning as parens but for readability, we will use them in some situations, e.g., around cond clauses.
Comments: double semicolon for full-line comments, single for partial line.
Ideally, code should be readable on its own without comments. Thus, any comments should be thought of as a failure to make the code readable, and should be used as sparingly as possible. More is definitely not better.
In this course, the design recipe mostly describes all the comments that should be in a program, so any comments beyond what is explained by the Design Recipe should be added very sparingly.
Naming: Predicate (function that returns a boolean) names have a ? suffix, e.g., string?.
Naming: multi-word identifiers, e.g. string-append, use - as the separator (not underscore or camelCase)
No "magic numbers". Define constants instead.
Naming: All constants must be named with an all-caps identifier.
4 Design Recipe Style
All code in this class must follow The Design Recipe.
use CapitalizedCamelCase for data definition names
for data definition predicates, use the same name but with a "?" suffix added
Write small functions!
This common advice is repeated so often because it makes code easier to read, easier to test, and reduces the possibility of introducing bugs that are difficult to find!
In this course, we adhere to the following guidelines for how to break up code into small functions:1 function should do
1 task that processes
1 kind of data
Conditionals
Avoid arbitrary conditionals such as if or cond, especially when they are nested. This usually produces large blocks of code that is difficult to read.
Instead, design data properly, and use conditionals only when called for by the data definition, e.g., itemizations. Most conditionals are used to different different kinds of data in a data definition.
When an if cannot be avoided, e.g., to maintain complex invariants in compound data: