Chapter 18: Clean Code & Idiomatic Swift Best Practices

Introduction

Welcome to Chapter 18! By now, you’ve built a solid foundation in Swift, covering everything from basic syntax to advanced topics like concurrency. But knowing how to write code is only half the battle. The other, equally crucial half, is knowing how to write good code. This means writing code that is not just functional, but also readable, maintainable, scalable, and robust. This is the essence of “Clean Code” and “Idiomatic Swift.”

In this chapter, we’ll dive deep into the principles and practices that define high-quality Swift code. We’ll explore how to leverage Swift’s unique features, such as its strong type system, protocol-oriented design, and modern concurrency model, to write code that is a pleasure to work with – for you and for anyone else who might read or modify it. We’ll focus on practical best practices that prepare you to build production-grade iOS applications that stand the test of time.

To get the most out of this chapter, you should be comfortable with Swift’s core language features, including optionals, error handling, protocols, extensions, closures, and the async/await concurrency model, as covered in previous chapters. Let’s make your Swift code shine!

Core Concepts: The Pillars of Clean & Idiomatic Swift

Writing clean and idiomatic Swift isn’t about following a rigid set of rules; it’s about adopting a mindset that prioritizes clarity, safety, and maintainability. Let’s explore the key principles.

1. Readability and Clarity: Your Code’s First Impression

Code is read far more often than it’s written. Making it easy to understand is paramount.

Naming Conventions

Swift has well-established naming conventions. Adhering to them makes your code immediately familiar to other Swift developers.

Types (Structs, Classes, Enums, Protocols): Use PascalCase (e.g., UserProfile, NetworkServiceError).
Variables, Constants, Functions, Methods, Parameters: Use camelCase (e.g., userName, fetchData(forUser:), process(input:)).
Boolean Variables: Start with verbs like is, has, can (e.g., isActive, hasPermission).

Why it matters: Consistent naming reduces cognitive load. When you see NetworkServiceError, you immediately know it’s a type. When you see userName, you know it’s a variable holding a user’s name.

Self-Documenting Code

The best code explains itself. This means:

Descriptive Names: Choose names that clearly convey the purpose of a variable, function, or type. Avoid abbreviations unless universally understood.
Small, Focused Functions/Methods: Each function should do one thing and do it well. If a function’s name needs to be “processAndValidateAndSaveUser,” it’s probably doing too much.
Minimize Comments (but don’t eliminate them): Comments should explain why something is done, not what is done (the code should explain what). Complex algorithms or business logic might warrant explanation.

Think about it: If you have to read a function’s implementation to understand what it does, its name or structure might need improvement.

2. Leveraging Swift’s Type System for Safety

Swift’s strong type system is a superpower. Use it to prevent bugs before they happen.

Optionals: Embrace Safety, Avoid Force Unwrapping

Optionals (?) are a core Swift feature, indicating that a value might be absent. Always unwrap optionals safely.

guard let: Ideal for early exit when a condition isn’t met. It makes your code flatter and easier to read.
if let: Use when you want to execute code only if an optional has a value.
Nil-Coalescing Operator (??): Provides a default value if an optional is nil.
Optional Chaining (?.): Safely call methods or access properties on an optional value.

Why it matters: Force unwrapping (!) is a common source of runtime crashes (nil pointer exceptions). Modern Swift code rarely uses ! outside of specific, controlled contexts (like IBOutlets that are guaranteed to be set by the system).

Enums with Associated Values

Enums are incredibly powerful for representing distinct states or a finite set of related values. Associated values allow you to attach additional data to each case.

// Bad: Using raw strings or integers, prone to typos and hard to manage
enum PaymentStatus {
    case "pending"
    case "completed"
    case "failed"
}

// Good: Using Swift Enums for clarity and type safety
enum PaymentStatus {
    case pending
    case completed(transactionID: String) // Associated value
    case failed(reason: PaymentFailureReason) // Another enum as associated value
}

enum PaymentFailureReason {
    case insufficientFunds
    case cardDeclined
    case networkError(errorCode: Int)
}

Why it matters: Enums enforce type safety and make your code self-documenting. They prevent invalid states and make switch statements exhaustive, ensuring you handle all possibilities.

Structs vs. Classes: Value vs. Reference Semantics

Understanding when to use a struct (value type) versus a class (reference type) is fundamental.

struct: Preferred for small, simple data models that don’t require inheritance or Objective-C interoperability. They are copied when passed around, preventing unexpected side effects.
class: Use when you need inheritance, Objective-C interoperability, or identity (e.g., a UIViewController instance).

General Rule: “Prefer structs over classes” unless you specifically need reference semantics or class features. This principle, often called “Value Semantics Everywhere,” leads to safer, more predictable code.

3. Protocol-Oriented Programming (POP)

Swift is heavily influenced by Protocol-Oriented Programming. Instead of relying solely on class inheritance, Swift encourages composition through protocols.

Define Behavior, Not Implementation: Protocols define a blueprint of methods, properties, or other requirements.
Small, Focused Protocols: Avoid “mega-protocols.” Each protocol should describe a single capability.
Extensions for Default Implementations: Provide default implementations for protocol requirements using extensions, making adoption easier.

// Example: A protocol for any type that can be identified
protocol Identifiable {
    var id: String { get }
}

// A protocol for any type that can be saved
protocol Savable {
    func save()
}

// Combine protocols for a specific type
struct User: Identifiable, Savable {
    let id: String
    var name: String

    func save() {
        print("Saving user \(name) with ID: \(id)")
    }
}

Why it matters: POP promotes flexible, reusable code. You can mix and match behaviors without the limitations of single inheritance. It’s a cornerstone of modern Swift architecture.

4. Robust Error Handling

Swift’s error handling (Error protocol, do-catch, try?, try!) is designed for clarity and safety.

Define Custom Error Types: Create enums that conform to the Error protocol to represent specific failure conditions.
Use do-catch for Recoverable Errors: When you expect an error and can handle it gracefully.
Use try? for Optional Results: When you want to convert an error into nil (e.g., trying to parse a string that might not be valid JSON).
Avoid try!: Only use try! when you are absolutely certain that an error will not be thrown, otherwise it will crash your app. This is rare in production code.

enum DataProcessingError: Error {
    case invalidInput
    case networkFailure(statusCode: Int)
    case decodingFailed
}

func processData(input: String) throws -> String {
    guard !input.isEmpty else {
        throw DataProcessingError.invalidInput
    }
    // ... imagine complex data processing that might fail
    return "Processed \(input)"
}

do {
    let result = try processData(input: "Hello")
    print(result)
    let failedResult = try processData(input: "")
    print(failedResult) // This line will not be reached
} catch DataProcessingError.invalidInput {
    print("Input was invalid!")
} catch DataProcessingError.networkFailure(let code) {
    print("Network failed with status code: \(code)")
} catch {
    print("An unexpected error occurred: \(error)")
}

Why it matters: Proper error handling makes your applications resilient. It allows you to anticipate problems and react to them without crashing, providing a better user experience.

5. Memory Management: Avoiding Retain Cycles

Swift uses Automatic Reference Counting (ARC) to manage memory. While ARC handles most of the work, you need to be aware of retain cycles, especially with closures and delegates.

weak references: Use for references that can become nil (e.g., delegates, parent-child relationships where the child shouldn’t keep the parent alive).
unowned references: Use for references that are guaranteed to always have a value as long as the current instance exists. If the unowned reference ever becomes nil while still being accessed, it will cause a runtime crash. Use with caution.

class HTMLElement {
    let name: String
    let text: String?

    // 'unowned' because a child element will always have a parent (or be nil when parent is deallocated)
    // and the parent owns the child.
    unowned var parent: HTMLElement?
    var children: [HTMLElement] = []

    init(name: String, text: String? = nil) {
        self.name = name
        self.text = text
    }

    deinit {
        print("\(name) is being deinitialized")
    }
}

// Example of a closure with a capture list to break a retain cycle
class DataFetcher {
    var completionHandler: ((String) -> Void)?

    func fetchData() {
        // Simulate an async network request
        DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [weak self] in // Capture self weakly
            guard let self = self else { return } // Safely unwrap weak self
            let data = "Some fetched data"
            self.completionHandler?(data)
            print("Data fetching complete.")
        }
    }

    deinit {
        print("DataFetcher is being deinitialized")
    }
}

var fetcher: DataFetcher? = DataFetcher()
fetcher?.completionHandler = { [weak fetcher] data in // Capture fetcher weakly if needed here
    print("Received data: \(data)")
    // If you need 'fetcher' inside this closure, use [weak fetcher]
}
fetcher?.fetchData()
fetcher = nil // DataFetcher will deinit after 2 seconds, thanks to [weak self]

Why it matters: Unresolved retain cycles lead to memory leaks, degrading app performance and potentially causing crashes. Understanding weak and unowned is critical for robust Swift development.

6. Modern Concurrency with Async/Await and Actors

Swift’s modern concurrency model is a game-changer for writing safe and efficient asynchronous code.

async/await: Use for structured, readable asynchronous operations. It replaces complex completion handlers and nested callbacks.
Structured Concurrency (Tasks & Task Groups): Organize your asynchronous work into a clear hierarchy, ensuring all child tasks are completed or cancelled when their parent task finishes.
Actors: The primary tool for isolating mutable state and preventing data races in concurrent environments. An actor ensures that only one piece of code can access its mutable state at any given time.

actor UserStore {
    private var users: [String: String] = [:]

    func addUser(id: String, name: String) {
        users[id] = name
    }

    func getUser(id: String) -> String? {
        return users[id]
    }
}

func fetchAndStoreUser(store: UserStore, id: String) async {
    // Imagine fetching user data asynchronously
    let userName = await simulateNetworkFetch(for: id)

    // Accessing actor's mutable state is done safely via 'await'
    await store.addUser(id: id, name: userName)
    print("Stored user: \(userName)")
}

func simulateNetworkFetch(for id: String) async -> String {
    try? await Task.sleep(for: .seconds(1))
    return "User_\(id)"
}

// How you'd use it:
// let store = UserStore()
// Task {
//     await fetchAndStoreUser(store: store, id: "123")
//     let user = await store.getUser(id: "123")
//     print("Retrieved user: \(user ?? "N/A")")
// }

Why it matters: Concurrency is hard. Swift’s modern tools make it significantly easier and safer, reducing the likelihood of common concurrency bugs like data races and deadlocks. Embrace them fully for any asynchronous work.

7. Performance Considerations

While readability and safety are paramount, being mindful of performance can lead to a snappier app.

Value Types for Small Data: Structs are often more performant than classes for small data because they are stack-allocated and don’t involve ARC overhead.
Lazy Initialization: Use lazy var for properties that are expensive to compute and might not always be needed.
Avoid Unnecessary Copies: Be aware of how collections and value types are copied. Pass large structs by inout or consider using classes if frequent mutations and copies are a bottleneck.
Compiler Optimizations: Swift’s compiler is highly optimized. Trust it, but profile your code if you suspect performance issues.

Think about it: Don’t prematurely optimize. Write clear, correct code first. If profiling reveals a bottleneck, then optimize that specific area.

Step-by-Step Implementation: Refactoring for Clarity

Let’s take a common scenario and refactor a piece of code to apply some of these best practices. Imagine you have a function that loads user data from a remote API.

Initial “Unclean” Code

Here’s a hypothetical initial implementation. Notice the force unwrapping, magic strings, and less-than-ideal error handling.

// Code Snippet 1: Initial, less-than-idiomatic code
import Foundation

class UserDataLoader {
    func loadUserData(userId: String, completion: @escaping (String?) -> Void) {
        let urlString = "https://api.example.com/users/\(userId)"
        let url = URL(string: urlString)! // Force unwrap! What if urlString is invalid?

        URLSession.shared.dataTask(with: url) { data, response, error in
            if error != nil {
                print("Network error: \(error!.localizedDescription)") // Force unwrap error
                completion(nil)
                return
            }

            guard let httpResponse = response as? HTTPURLResponse,
                  httpResponse.statusCode == 200 else {
                print("Invalid response or status code.")
                completion(nil)
                return
            }

            if let data = data,
               let jsonString = String(data: data, encoding: .utf8) {
                completion(jsonString) // Returning raw JSON string
            } else {
                print("Failed to decode data.")
                completion(nil)
            }
        }.resume()
    }
}

Explanation of issues:

URL(string: urlString)!: A potential crash point if the urlString is malformed.
completion: @escaping (String?) -> Void: Returns an optional String, making it unclear if nil means network error, invalid response, or decoding failure.
print statements for error handling: Not scalable or testable.
Returning raw String instead of a structured User type.
Uses completion handlers, which modern Swift prefers to replace with async/await.

Step 1: Define a `User` Model and Custom Errors

First, let’s create a User struct that conforms to Decodable and define clear error types.

Add this code:

// Code Snippet 2: User model and custom errors
import Foundation

// 1. Define a Codable User model
struct User: Codable, Identifiable {
    let id: String
    let name: String
    let email: String
    // Add more properties as needed
}

// 2. Define custom error types for clarity
enum UserDataLoaderError: Error, LocalizedError {
    case invalidURL
    case networkError(Error)
    case invalidResponse(statusCode: Int)
    case decodingError(Error)
    case unknownError

    var errorDescription: String? {
        switch self {
        case .invalidURL:
            return "The provided URL was invalid."
        case .networkError(let error):
            return "A network error occurred: \(error.localizedDescription)"
        case .invalidResponse(let statusCode):
            return "Received an invalid HTTP response with status code: \(statusCode)"
        case .decodingError(let error):
            return "Failed to decode user data: \(error.localizedDescription)"
        case .unknownError:
            return "An unknown error occurred."
        }
    }
}

Explanation:

We created a User struct that conforms to Codable (which combines Encodable and Decodable). This is idiomatic for data models.
Identifiable is a common protocol for models.
UserDataLoaderError is an enum conforming to Error and LocalizedError. This gives us structured, expressive error types and user-friendly error messages.

Step 2: Refactor `loadUserData` with `async/await` and Error Handling

Now, let’s update the UserDataLoader to use async/await and our new error types.

Modify the UserDataLoader class:

// Code Snippet 3: Refactored UserDataLoader with async/await and structured errors
import Foundation

class UserDataLoader {
    // Use an async function that throws specific errors and returns a User
    func loadUserData(userId: String) async throws -> User {
        // 1. Safely construct URL
        guard let url = URL(string: "https://api.example.com/users/\(userId)") else {
            throw UserDataLoaderError.invalidURL
        }

        // 2. Perform network request using async/await
        let (data, response) = try await URLSession.shared.data(from: url)

        // 3. Validate HTTP response
        guard let httpResponse = response as? HTTPURLResponse else {
            throw UserDataLoaderError.unknownError // Should ideally be more specific
        }

        guard (200...299).contains(httpResponse.statusCode) else {
            throw UserDataLoaderError.invalidResponse(statusCode: httpResponse.statusCode)
        }

        // 4. Decode data into User struct
        do {
            let user = try JSONDecoder().decode(User.self, from: data)
            return user
        } catch {
            throw UserDataLoaderError.decodingError(error)
        }
    }
}

Explanation:

The function is now async throws -> User, clearly indicating it’s asynchronous, can fail, and returns a User object on success.
guard let url = ... else { throw ... } safely handles URL creation, replacing the force unwrap.
let (data, response) = try await URLSession.shared.data(from: url) is the modern way to perform network requests, replacing the old completion handler syntax.
HTTP status code checking is more robust.
JSONDecoder().decode(...) is used within a do-catch block to handle decoding errors explicitly, wrapping them in our custom UserDataLoaderError.

Step 3: Using the Refactored Data Loader

Now, let’s see how much cleaner and safer the call site becomes.

Add this code:

// Code Snippet 4: Using the refactored data loader
// In an async context, e.g., a Task or an async function
func fetchAndDisplayUser(id: String) async {
    let dataLoader = UserDataLoader()
    do {
        let user = try await dataLoader.loadUserData(userId: id)
        print("Successfully loaded user: \(user.name), Email: \(user.email)")
    } catch let error as UserDataLoaderError {
        print("Failed to load user: \(error.localizedDescription)")
        // You can now react specifically to different error types
        switch error {
        case .invalidURL:
            print("Please check the user ID format.")
        case .networkError(let underlyingError):
            print("Underlying network issue: \(underlyingError.localizedDescription)")
        case .invalidResponse(let statusCode):
            print("Server returned unexpected status: \(statusCode)")
        case .decodingError:
            print("Server data format was unexpected.")
        case .unknownError:
            print("An unexpected issue occurred.")
        }
    } catch {
        print("An unforeseen error occurred: \(error.localizedDescription)")
    }
}

// To run this example, you'd typically call it from a Task:
Task {
    await fetchAndDisplayUser(id: "123")
    // Simulate an invalid ID or other error scenario
    await fetchAndDisplayUser(id: "invalid_id_format_that_will_fail_url_creation")
}

Explanation:

The fetchAndDisplayUser function is async to call loadUserData.
A do-catch block elegantly handles all potential errors from loadUserData.
We use catch let error as UserDataLoaderError to specifically handle our custom errors, allowing for granular error messages and recovery strategies.
The switch statement on the error type demonstrates how you can provide specific feedback to the user or handle different failure modes.

This refactoring showcases how async/await, custom error types, and safe optional handling lead to dramatically cleaner, more robust, and easier-to-understand code.

Mini-Challenge: Refine a Configuration Manager

You’ve just learned how to apply clean code principles. Now, let’s tackle a small challenge.

Challenge: You have a ConfigurationManager that reads a string value from a dictionary. Refactor the getValue(forKey:) method to be more idiomatic Swift. Specifically:

Replace the force cast as! String.
Return an optional String to indicate that a value might not be found.
Consider how to handle the case where the key exists but the value is not a String.

// Original code for the challenge
class ConfigurationManager {
    private let config: [String: Any] = [
        "appName": "MyAwesomeApp",
        "version": 1.0, // This is a Double, not a String!
        "apiEndpoint": "https://api.myapp.com",
        "debugMode": true
    ]

    func getValue(forKey key: String) -> String {
        return config[key] as! String // Potential crash if key doesn't exist or value isn't String
    }
}

// Example usage that might crash:
// let manager = ConfigurationManager()
// print(manager.getValue(forKey: "appName"))
// print(manager.getValue(forKey: "nonExistentKey")) // CRASH!
// print(manager.getValue(forKey: "version")) // CRASH!

Hint: Think about optional chaining (?) and optional casting (as?). What’s the best way to return nil if a value isn’t found or isn’t of the expected type?

What to observe/learn: How to safely retrieve and cast values from a dictionary, using Swift’s type safety features to prevent runtime errors.

Click for Solution (after you've tried it!)

class ConfigurationManager {
    private let config: [String: Any] = [
        "appName": "MyAwesomeApp",
        "version": 1.0,
        "apiEndpoint": "https://api.myapp.com",
        "debugMode": true
    ]

    // Refactored method to return an optional String
    func getValue(forKey key: String) -> String? {
        // Safely try to get the value, then safely try to cast it to String
        return config[key] as? String
    }
}

// Example usage with the refactored method:
let manager = ConfigurationManager()

if let appName = manager.getValue(forKey: "appName") {
    print("App Name: \(appName)") // Output: App Name: MyAwesomeApp
} else {
    print("App Name not found or is not a String.")
}

if let apiEndpoint = manager.getValue(forKey: "apiEndpoint") {
    print("API Endpoint: \(apiEndpoint)") // Output: API Endpoint: https://api.myapp.com
} else {
    print("API Endpoint not found or is not a String.")
}

// This now safely returns nil, no crash!
if let nonExistent = manager.getValue(forKey: "nonExistentKey") {
    print("Non-existent key: \(nonExistent)")
} else {
    print("Non-existent key not found or is not a String.") // Output: Non-existent key not found or is not a String.
}

// This now safely returns nil, no crash!
if let version = manager.getValue(forKey: "version") {
    print("Version: \(version)")
} else {
    print("Version not found or is not a String.") // Output: Version not found or is not a String.
}

Explanation of Solution: The key is config[key] as? String.

config[key] attempts to retrieve the value for the key. Since dictionary lookup returns an optional (Any?), this is already safe.
as? String is an optional cast. It attempts to cast the Any? value to a String. If the cast succeeds, it returns String? containing the String. If the cast fails (either because the key wasn’t found, or the value was not a String), it returns nil. This is the safest and most idiomatic way to handle this scenario in Swift.

Common Pitfalls & Troubleshooting

Even with the best intentions, developers can stumble. Here are some common pitfalls in Swift and how to avoid them:

Over-Reliance on Force Unwrapping (!):
- Pitfall: Using ! on optionals, assuming a value will always be present. This leads to runtime crashes (EXC_BAD_ACCESS or “unexpectedly found nil while unwrapping an Optional value”) if the optional is nil.
- Solution: Always prefer safe unwrapping methods: if let, guard let, nil-coalescing operator (??), and optional chaining (?.). Reserve ! only for situations where you are 100% certain the value exists (e.g., IBOutlets after viewDidLoad, or URLs constructed from known valid strings in tests).
Massive View Controllers (MVC “Massive View Controller”):
- Pitfall: Placing too much logic (networking, data processing, business rules, multiple delegate implementations) directly within UIViewController subclasses. This makes them hard to read, test, and maintain.
- Solution: Follow architectural patterns like MVVM (Model-View-ViewModel), VIPER, or Clean Architecture. Delegate responsibilities: move networking to a NetworkService, data storage to a Repository, business logic to a ViewModel or Presenter.
Retain Cycles with Closures and Delegates:
- Pitfall: Two objects holding strong references to each other, preventing ARC from deallocating either, leading to memory leaks. Common with closures that capture self strongly, or delegate patterns where the delegate holds a strong reference to its delegator.
- Solution: Use [weak self] or [unowned self] in closure capture lists. For delegates, the delegator should hold a weak reference to its delegate. Always be mindful of object ownership and reference types.
Inconsistent Code Style:
- Pitfall: Mixing naming conventions, indentation styles, or code organization patterns. This makes the codebase look messy and harder to navigate for new team members.
- Solution: Adopt a consistent style guide (e.g., Apple’s Swift API Design Guidelines, or a team-specific guide). Use code formatters like SwiftFormat or integrate linting tools into your build process to automate style enforcement.

Troubleshooting Tip: When encountering a crash related to nil unwrapping, the debugger is your best friend. Set a breakpoint on the line causing the crash and inspect the values of all variables involved. You’ll often find that an optional you expected to have a value is, in fact, nil.

Summary

Congratulations! You’ve explored the essential principles of writing clean, idiomatic Swift code. By internalizing these practices, you’re not just writing functional software; you’re crafting high-quality, maintainable, and robust applications.

Here are the key takeaways from this chapter:

Prioritize Readability: Use clear, descriptive naming conventions (PascalCase for types, camelCase for variables/functions) and make your code self-documenting.
Leverage Swift’s Type System: Embrace optionals and safe unwrapping (guard let, if let, ??) to prevent crashes. Use enums with associated values for type-safe states and data. Understand struct vs. class for value vs. reference semantics.
Embrace Protocol-Oriented Programming (POP): Design with small, focused protocols and use extensions for default implementations to build flexible, reusable code.
Implement Robust Error Handling: Define custom Error types and use do-catch blocks for clear, recoverable error management. Avoid try!.
Be Mindful of Memory Management: Use weak or unowned references to prevent retain cycles, especially with closures and delegates, to avoid memory leaks.
Adopt Modern Concurrency: Utilize async/await for structured asynchronous code and Actors for safe, isolated mutable state management in concurrent environments.
Consider Performance Thoughtfully: Optimize only when profiling reveals a bottleneck, preferring clear code first.

By consistently applying these best practices, you’ll not only write better Swift code but also become a more effective and respected software engineer. This commitment to quality is what truly prepares you to build production-grade iOS applications.

What’s next? With a strong understanding of clean code, you’re now ready to apply these principles as you dive into larger projects and architectural patterns, building sophisticated and maintainable applications.

References

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.

Chapter 18: Clean Code & Idiomatic Swift Best Practices

Table of Contents

Introduction

Core Concepts: The Pillars of Clean & Idiomatic Swift

1. Readability and Clarity: Your Code’s First Impression

Naming Conventions

Self-Documenting Code

2. Leveraging Swift’s Type System for Safety

Optionals: Embrace Safety, Avoid Force Unwrapping

Enums with Associated Values

Structs vs. Classes: Value vs. Reference Semantics

3. Protocol-Oriented Programming (POP)

4. Robust Error Handling

5. Memory Management: Avoiding Retain Cycles

6. Modern Concurrency with Async/Await and Actors

7. Performance Considerations

Step-by-Step Implementation: Refactoring for Clarity

Initial “Unclean” Code

Step 1: Define a User Model and Custom Errors

Step 2: Refactor loadUserData with async/await and Error Handling

Step 3: Using the Refactored Data Loader

Mini-Challenge: Refine a Configuration Manager

Common Pitfalls & Troubleshooting

Summary

References

Step 1: Define a `User` Model and Custom Errors

Step 2: Refactor `loadUserData` with `async/await` and Error Handling