Table of Contents

1. Challenge

   Step 1: Orientation to the RiverFit Studio booking engine

   Step 1: Orientation to the RiverFit Studio booking engine

   RiverFit Studio runs its fitness classes out of a single room, back-to-back, six days a week. Until now, the front desk has tracked seats, calories, and schedules on a paper sign-in sheet -- and it's starting to show: double-booked slots, miscounted seats, and at least one badge code that turned out to be someone's cat's name. You're building the value-handling core of the replacement booking engine: the part that decides whether a class has room, whether a badge code is real, and whether a class's start and end times actually fit the day. ## What you're building

   Your work lands in four files under src/:

   • SessionLedger.cs -- tracks a class's seat capacity, a member's calorie burn, and a running attendance total.
   • MembershipCode.cs -- validates the alphanumeric codes printed on member badges.
   • ClassSchedule.cs -- constructs and shifts a class session's start and end times.
   • BookingService.cs -- ties all three together into one booking call the front-desk screen invokes.

   Each file already compiles; the methods you'll complete are marked with // TODO: Task <n> comments and a // Hint: line above them. ## How the next four steps build on each other

   Step 2 starts small: you'll pick numeric types that fit the values they hold and write arithmetic that respects C#'s operator precedence inside SessionLedger.cs. Step 3 stays in that file to guard against integer overflow, then moves to MembershipCode.cs to classify characters one at a time. Step 4 introduces DateTime and TimeSpan in ClassSchedule.cs to build and shift class times. Step 5 assembles BookingService.cs, where a mistyped date has to fail as a caught runtime exception instead of crashing the whole booking screen. ## Running the tests

   Every task has a matching test in tests/. From the project root, run:

   dotnet test tests/Lab.Tests.csproj --nologo --verbosity quiet
   

   Run it after every task -- a passing test is your signal to move to the next one. If a step's build fails entirely, re-check the most recent method you edited before assuming a later task is broken.

   If you get stuck, you can refer to the provided solution code for each task, available in the solution folder.

   info> This lab experience was developed by the Pluralsight team using an internally developed AI tool. All sections were verified by human experts for accuracy prior to publications. However, content may still contain errors or inaccuracies, and we recommend independent verification.
   
   To report a problem or provide feedback, click here. Feedback may be used to improve accuracy in accordance with our Privacy Policy.

2. Challenge

   Step 2: Build the foundational capacity and calorie calculations

   Step 2: Build the foundational capacity and calorie calculations

   SessionLedger.cs is where a class's numbers live: how many seats are left, how many calories a member burned, and how intense the session was. The type you pick for each of those numbers matters. An int can't hold a fraction, so a calorie formula that divides by 60 using integer division silently rounds a 45-minute class down to 0 minutes' worth of burn. A double keeps that fraction, at the cost of a little extra memory -- a trade worth making for anything computed from a formula rather than counted one at a time. ## Getting the arithmetic order right

   C# evaluates * and / before + and -, left to right, exactly like the order of operations you'd use on paper -- which means an expression written without parentheses doesn't always mean what it looks like it means. heartRateReserve + baseline * durationMinutes multiplies baseline by durationMinutes first and adds heartRateReserve on top of that product, not the sum you probably intended. Parentheses aren't decoration here; they're the only way to force addition to happen before multiplication. ## Keeping a running total idiomatic

   A calorie ledger that accumulates across a whole session needs to update the same field over and over. Writing RunningCalories = RunningCalories + amount works, but it reads the field twice for no reason. C#'s compound assignment operators -- +=, -=, *=, /= -- do the same update in one read-and-write step, and they're what any C# codebase will expect to see for a running total.

3. Challenge

   Step 3: Inspect integer boundaries and classify membership codes

   Step 3: Inspect integer boundaries and classify membership codes

   SessionLedger.cs already tracks a running attendance count, but it doesn't have to fit in a room -- it's the studio's all-time total, and a busy year can push it close to what an int can hold. Every integer type exposes its own ceiling and floor as constants: int.MaxValue is 2,147,483,647, and adding past it doesn't throw -- it silently wraps around to a large negative number. Checking amount > int.MaxValue - currentTotal before adding is the standard way to catch that wraparound before it corrupts a stored total. ## Classifying characters in a membership code

   MembershipCode.cs validates the codes printed on member badges, and that means inspecting individual characters rather than the string as a whole. C#'s char type ships with classification members built for exactly this -- char.IsDigit, char.IsLetter, char.IsWhiteSpace -- each one answering a yes/no question about a single character without you having to compare it against '0' through '9' or 'A' through 'z' by hand. ## Combining character checks into one validation

   Counting digits is only half of what a valid badge code needs. RiverFit's codes are a fixed length with a minimum number of digits and a minimum number of letters, and none of those three conditions implies the others -- a code can be the right length with zero digits, or have enough digits but be too short. Validating the whole code means checking all three conditions and only accepting a code when every one of them holds.

4. Challenge

   Step 4: Construct and adjust class session times

   Step 4: Construct and adjust class session times

   ClassSchedule.cs is where a class's date and time components -- entered separately at the front desk -- become one DateTime value the rest of the engine can compare, sort, and shift. The DateTime constructor that takes year, month, day, hour, and minute builds exactly that value, and every later calculation in this step builds on top of it. ## Shifting a DateTime with TimeSpan

   A class's end time isn't a separate fact the front desk enters -- it's the start time plus however long the class runs. TimeSpan represents that duration, and DateTime supports adding a TimeSpan directly with +, correctly rolling over into the next hour, or even the next day, without any manual carrying. ## Measuring the gap between two DateTimes

   Subtracting one DateTime from another produces a TimeSpan, and that's exactly the value RiverFit's front desk needs to know whether there's real turnover time between two back-to-back classes -- or whether the next class has been scheduled to start before the current one has even ended.

5. Challenge

   Step 5: Wire booking validation with exception-safe date handling

   Step 5: Wire booking validation with exception-safe date handling

   BookingService.cs is where everything you've built comes together, and it's also where a front-desk typo can do real damage. Typing month = 2, day = 30 compiles just fine -- the error only shows up when new DateTime(2024, 2, 30) actually runs and throws an ArgumentOutOfRangeException. That's the core difference between a compile-time type error, which the compiler catches before the program ever runs, and a runtime exception, which only appears when the exact bad input reaches the exact line that can't handle it. Catching that exception is what keeps one bad date from taking down the whole booking screen. ## Combining independent checks into one result

   A booking is only valid when three unrelated things are all true at once: the date parsed, the membership code is well-formed, and the class still has room. None of those checks can stand in for another, so combining them means evaluating all three and only reporting success when every one passes -- exactly the job &&'s short-circuiting behavior is built for. ## Assembling the single booking call

   The front-desk screen doesn't call three separate validation methods -- it calls one BookSession method and gets back one pass/fail answer. That means chaining the date parse into the combined validation, and only mutating the ledger's seat count when every check has already passed.

6. Challenge

   Step 6: Run the application

   Every task is done, and each one was graded the moment you completed it. What you have not done yet is watch the whole application run at once -- which is the only place the pieces you wrote separately become a single working program.

   Start the application

   Open the Terminal tab and run:

   dotnet run --project src/Lab.csproj
   

   The program runs in the terminal and prints its output there. Every behaviour it shows is code you wrote in the previous steps, so read the output against what each task asked for -- that is the whole lab, working as one program. ### Run the checks yourself

   The lab ran each task's test for you as you went, but they are ordinary tests and you can run them whenever you like. The whole suite:

   dotnet test tests/Lab.Tests.csproj --nologo --verbosity quiet
   

   Or one task at a time:

   bash runTest.sh Task_2_1
   

   Each failure names the task it belongs to, so the output tells you which step to go back to rather than which line to stare at. Two things worth trying before you finish: break something on purpose and watch the matching check fail, then put it back. Knowing what a failure looks like is worth as much as knowing what a pass looks like, and it costs you nothing here.

   When you are done, everything you wrote is still in the editor tabs -- the lab is yours to keep reading.