Compute both n % 3 == 0 and n % 5 == 0 as a tuple (n % 3, n % 5), then switch on that tuple using pattern matching — check the "both zero" case before checking either one alone.

static void PrintFizzBuzz(int max)
{
    for (int n = 1; n <= max; n++)
    {
        string result = (n % 3, n % 5) switch
        {
            (0, 0) => "FizzBuzz",
            (0, _) => "Fizz",
            (_, 0) => "Buzz",
            _      => n.ToString()
        };
        Console.WriteLine(result);
    }
}

Why this works: the tuple pattern (0, 0) must be checked before (0, _) and (_, 0) — switch expressions test patterns top-to-bottom and use the first match, so ordering the "both" case first is what makes 15, 30, 45... correctly produce "FizzBuzz" instead of stopping at "Fizz". The loop bound is n <= max since we genuinely want to include max itself here, unlike an index-based loop over a collection.

First, build a "cleaned" version of the string containing only letters, all lowercase (loop through each character, check char.IsLetter, and append the lowercase version to a new string or a StringBuilder). Then compare that cleaned string to its own reversed form.

static bool IsPalindrome(string text)
{
    string cleaned = "";
    foreach (char c in text)
    {
        if (char.IsLetter(c))
            cleaned += char.ToLower(c);
    }

    int left = 0;
    int right = cleaned.Length - 1;
    while (left < right)
    {
        if (cleaned[left] != cleaned[right])
            return false;
        left++;
        right--;
    }
    return true;
}

Why this works: instead of building a fully reversed string and comparing it, this uses two pointers — one starting at the front, one at the back — walking toward the middle. The moment any pair of mirrored characters doesn't match, it returns false immediately without checking the rest. If the pointers meet or cross without a mismatch, it's a palindrome. Note the careful loop bound left < right — not <= — since once they meet or pass each other, every pair has already been checked.

This is pure encapsulation: keep the field private (e.g., _balance), expose it only through a get-only Balance property, and put every validation check as a guard clause at the top of Deposit and Withdraw before touching the field.

public class BankAccount
{
    private decimal _balance;
    public decimal Balance => _balance;

    public void Deposit(decimal amount)
    {
        if (amount <= 0)
            throw new ArgumentException("Deposit amount must be positive.", nameof(amount));
        _balance += amount;
    }

    public void Withdraw(decimal amount)
    {
        if (amount <= 0)
            throw new ArgumentException("Withdrawal amount must be positive.", nameof(amount));
        if (amount > _balance)
            throw new InvalidOperationException("Insufficient funds.");
        _balance -= amount;
    }
}

Why this works: _balance can never be modified from outside the class — the only doors in are Deposit and Withdraw, and both refuse to let the account enter an invalid state. Using ArgumentException for bad input and InvalidOperationException for a valid-but-currently-impossible operation (overdrawing) follows the standard .NET convention of choosing an exception type that describes why the operation failed.

This is the same pattern as the Employee System project: a List<Shape> can hold a mix of concrete subclasses, and calling the abstract method through a foreach loop automatically dispatches to each object's own override.

public abstract class Shape
{
    public abstract decimal Area();
}

public class Circle : Shape
{
    public decimal Radius { get; }
    public Circle(decimal radius) => Radius = radius;
    public override decimal Area() => 3.14159m * Radius * Radius;
}

public class Rectangle : Shape
{
    public decimal Width { get; }
    public decimal Height { get; }
    public Rectangle(decimal width, decimal height) => (Width, Height) = (width, height);
    public override decimal Area() => Width * Height;
}

static decimal TotalArea(List<Shape> shapes)
{
    decimal total = 0;
    foreach (var shape in shapes)
        total += shape.Area();     // polymorphism — correct override runs per shape
    return total;
}

Why this works: TotalArea never asks "is this a Circle or a Rectangle?" — it just calls Area() and trusts virtual dispatch to run the correct implementation for whatever concrete object is actually there. This is exactly why Area() was declared abstract on Shape: it guarantees every subclass must supply one, so this loop can never accidentally call a missing implementation.

This is a direct callback to the "mutating a collection while iterating" mistake — you cannot safely call inventory.Remove(...) from inside a foreach (var item in inventory). Loop over a copy of the list instead, or loop backward by index.

static void RemoveExpiredItems(List<string> inventory, List<string> expiredNames)
{
    // Loop over a snapshot copy, remove from the real list
    foreach (var item in inventory.ToList())
    {
        if (expiredNames.Contains(item))
            inventory.Remove(item);
    }
}

Why this works: inventory.ToList() creates an independent copy of the list at that moment, so the foreach is iterating over the copy — which never changes — while inventory.Remove(item) safely modifies the real, original list. No enumerator ever sees a collection change mid-iteration, so no exception is thrown.

Define public class InvalidPositiveIntegerException : Exception with a constructor that just forwards a message to the base Exception(string message) constructor. Use int.TryParse first to catch non-numeric text before separately checking the sign of a successfully parsed number.

public class InvalidPositiveIntegerException : Exception
{
    public InvalidPositiveIntegerException(string message) : base(message) { }
}

static int ParsePositiveInteger(string input)
{
    if (!int.TryParse(input, out int value))
        throw new InvalidPositiveIntegerException($"'{input}' is not a valid whole number.");

    if (value <= 0)
        throw new InvalidPositiveIntegerException($"{value} is not a positive number.");

    return value;
}

// Example usage:
try
{
    int quantity = ParsePositiveInteger(Console.ReadLine() ?? "");
    Console.WriteLine($"Quantity accepted: {quantity}");
}
catch (InvalidPositiveIntegerException ex)
{
    Console.WriteLine($"Invalid input: {ex.Message}");
}

Why this works: a custom exception type lets the caller catch exactly this failure mode specifically (via catch (InvalidPositiveIntegerException ex)) without accidentally swallowing unrelated exceptions the way a broad catch (Exception ex) would. Checking TryParse first, separately from the sign check, means the exception message is genuinely specific to which rule was actually broken.

This mirrors exactly what SaveToFile/LoadFromFile did in the Expense Tracker project. Check File.Exists at the very top of LoadBooks before attempting to read anything.

using System.Text.Json;

public record Book(string Title, string Author, int Year);

static void SaveBooks(List<Book> books, string path)
{
    var options = new JsonSerializerOptions { WriteIndented = true };
    string json = JsonSerializer.Serialize(books, options);
    File.WriteAllText(path, json);
}

static List<Book> LoadBooks(string path)
{
    if (!File.Exists(path))
        return new List<Book>();

    string json = File.ReadAllText(path);
    var books = JsonSerializer.Deserialize<List<Book>>(json);
    return books ?? new List<Book>();
}

Why this works: Book being a record means System.Text.Json can serialize and deserialize it automatically, since records expose their data through ordinary public properties under the hood. The File.Exists check before reading avoids a FileNotFoundException entirely on a fresh run, and books ?? new List<Book>() guards against Deserialize returning null (which can happen if the file contains the literal text "null").

Count the items in _items, then count exactly which values i takes in the loop. Compare that against valid list indices.

The bug: _items has 3 elements, so its valid indices are 0, 1, and 2. The loop starts at i = 1 and runs through i = 3 (inclusive, because of i <= 3) — a double off-by-one mistake. It skips index 0 ("Hammer" is never printed) and reaches for index 3, which doesn't exist.

The stack trace would look approximately like this:

Unhandled exception. System.ArgumentOutOfRangeException: Index was out of range.
   at System.Collections.Generic.List`1.get_Item(Int32 index)
   at Inventory.GetItemAt(Int32 position) in Program.cs:line 6
   at Program.Main() in Program.cs:line 16

Reading top-down: the exception is thrown inside the framework's own List<T> indexer, called from GetItemAt at line 6 (the return _items[position]; line), called from Main at line 16 (inside the loop). This confirms exactly what the manual read-through found.

The fix: the loop should run for (int i = 0; i < 3; i++) — or better yet, avoid hardcoding the count entirely and use i < inventory.Count style logic if Inventory exposed a count, or simplest of all, have Inventory expose a way to enumerate its items directly with foreach.

This combines Challenge 4's polymorphism (an abstract method that varies by subclass), Challenge 6's custom exception pattern, and a plain foreach search loop like the ones in both projects. Search for the match with a loop and an if, don't use LINQ's FirstOrDefault.

public class ItemNotFoundException : Exception
{
    public ItemNotFoundException(string title)
        : base($"No library item found with title '{title}'.") { }
}

public abstract class LibraryItem
{
    public string Title { get; }
    protected LibraryItem(string title) => Title = title;
    public abstract int GetLoanPeriodDays();
}

public class Book : LibraryItem
{
    public Book(string title) : base(title) { }
    public override int GetLoanPeriodDays() => 14;
}

public class DVD : LibraryItem
{
    public DVD(string title) : base(title) { }
    public override int GetLoanPeriodDays() => 7;
}

public class Library
{
    private readonly List<LibraryItem> _items = new();

    public void AddItem(LibraryItem item) => _items.Add(item);

    public DateTime CheckOut(string title)
    {
        LibraryItem? found = null;
        foreach (var item in _items)
        {
            if (item.Title == title)
            {
                found = item;
                break;
            }
        }

        if (found is null)
            throw new ItemNotFoundException(title);

        return DateTime.Today.AddDays(found.GetLoanPeriodDays());
    }
}

// Example usage:
var library = new Library();
library.AddItem(new Book("Clean Code"));
library.AddItem(new DVD("The Matrix"));

try
{
    DateTime dueDate = library.CheckOut("Clean Code");
    Console.WriteLine($"Due back: {dueDate:yyyy-MM-dd}");   // 14 days from today

    library.CheckOut("A Missing Title");                     // throws
}
catch (ItemNotFoundException ex)
{
    Console.WriteLine($"Checkout failed: {ex.Message}");
}

Why this works: found is declared as a nullable LibraryItem?, since it's entirely possible no match exists — the loop uses break to stop scanning the instant a match is found (no point checking the rest), and the is null check afterward decides whether to throw. GetLoanPeriodDays() is where polymorphism does the real work: Library.CheckOut never needs to know or care whether it's holding a Book or a DVD — it just asks the item for its own loan period and trusts the correct override to run.