Code Style Conventions

NOTE

To date, we have relied on learning code style conventions through the examples provided in activities and lessons.

Here is a summary of code style conventions to adhere to when writing software within your group projects and individual work.

Mr. Gordon generated this summary using the Claude large language model made by Anthropic. He then lightly edited the resulting examples.

This is a concise reference for structures, instances, stored properties, computed properties, and functions.

Structures

Convention: UpperCamelCase (PascalCase)

Type names — structs, classes, enums, protocols, and SwiftUI Views — always start with a capital letter. Each subsequent word is also capitalised. No underscores.

• Describes what the type is, not what it does.
• SwiftUI views should be nouns or noun phrases matching their role in the UI.
• Protocols are often named with an -able or -ing suffix.

struct BookCard: View { ... }        // ✓ view type
struct StudentProfile { ... }        // ✓ model type
enum   NetworkError: Error { ... }   // ✓ enum type
protocol Displayable { ... }         // ✓ protocol (-able suffix)
 
struct bookcard { ... }              // ✗ lowercase
struct Book_Card { ... }             // ✗ underscore

Instances

Convention: lowerCamelCase

Variable and constant names — including stored properties of a structure that use SwiftUI property wrappers like @State and @Binding — always start lowercase. Names should read clearly without needing a comment.

• Booleans should read as assertions: isLoading, hasSelection, canSubmit.
• Avoid redundant type information: prefer students over studentArray.

let studentProfile = StudentProfile(...)   // ✓ constant instance
var selectedIndex: Int = 0                 // ✓ variable
 
@State private var isLoading = false       // ✓ boolean state
@State private var searchText = ""         // ✓ string state
 
var StudentProfile = ...                   // ✗ uppercase
var student_profile = ...                  // ✗ underscore

Stored Properties

Convention: lowerCamelCase — noun or noun phrase

Stored properties hold a value directly in memory. Name them as nouns describing the data they hold. Use let for constants and var for mutable values.

• Prefer let wherever mutation isn’t needed.

struct Book {
    let    title:     String          // ✓ immutable
    let    author:    String
    var    pageCount: Int             // ✓ mutable
}
 
// ✗ avoid
var strTitle: String  // type prefix (Hungarian notation)

Computed Properties

Convention: lowerCamelCase — noun, no verb

Computed properties derive a value on demand; they have no backing storage. Name them like stored properties (nouns), not like functions (verbs).

Callers shouldn’t need to know whether they are using a stored property or a computed property.

• Side-effect-free — a computed property should only read state, never mutate it.
• If computation is expensive, prefer a method so callers know a cost is incurred.

struct Book {
    let title: String
    let author: String
 
    var displayName: String {          // ✓ noun, derived value
        "\(title) by \(author)"
    }
 
    var isLong: Bool {                 // ✓ boolean assertion
        pageCount > 400
    }
}
 
// ✗ avoid — reads like a function call
var getDisplayName: String { ... }

Functions & Methods

Convention: lowerCamelCase — verb phrase at the call site

Functions and methods are named with a verb (or verb phrase) describing their effect or return value. The Swift API Design Guidelines distinguish between mutating (verb: sort()) and non-mutating (past-participle or noun: sorted()) forms.

• The first argument label is often omitted when the function name reads naturally without it.
• Boolean-returning functions read as assertions at the call site: isEmpty, contains(_:).
• Mutating methods use a verb; non-mutating counterparts use past-participle or noun form.

// ✓ clear verb, reads well at the call site
func loadBooks() async throws -> [Book]
 
// ✓ first label omitted — reads as an English phrase
func index(of book: Book) -> Int?
// usage: list.index(of: myBook)
 
// ✓ mutating vs. non-mutating pair
books.sort()                       // mutates in place
let sorted = books.sorted()        // returns new value
 
// ✗ avoid — "get" prefix is redundant in Swift
func getBooks() -> [Book]

Key Principles

Use case as a signal. Swift uses capitalisation to signal the kind of thing you’re naming — UpperCamelCase for data types, lowerCamelCase for everything else. Underscores essentially don’t appear in idiomatic Swift.

Names should read well at the use site. The Swift API Design Guidelines emphasise that names are evaluated where they’re called, not where they’re declared. A function declared as func index(of book: Book) reads as list.index(of: myBook) — just like a natural English phrase.

Properties vs. methods as a contract. Computed properties signal “this is cheap and side-effect-free.” If deriving a value is expensive, surface it as a method so callers know a cost is incurred — that’s an implicit API promise.

Reference

To learn more: Swift API Design Guidelines