Lectures

We break down how to design reports as a sequence of steps “data → transformations → totals → text”: early key normalization ( trim(), lowercase()), filtering, grouping via groupBy()/ groupingBy() + eachCount(), aggregation with fold(), view preparation (sorting, take(n)) and rendering to a string via StringBuilder. Separately, we pin down why it’s important to track type changes ( List → Map) and not mix computation with output.

We break down how to make long chains of collection operations in Kotlin readable: where to place “breakpoints” via intermediate val, when to extract steps into separate functions with an “input → output” contract, how to control the “type ladder” ( List → Map → String), and which mistakes most often ruin reusability (side effects, bad names, “do-everything” combiners).

We break down how to write reports as a set of pure functions: separate computation from presentation, move side effects (for example, println) to the boundary ( CLI), avoid mutating input collections ( List/ Map instead of MutableList/ MutableMap), use fold for neat accumulation, and allow only local mutation like StringBuilder inside rendering.

We go through “silent” pipeline breakages in Kotlin: a lost result for sorted()/ filter()/ map() operations, incorrect use of map for side effects (and an unexpected List of Unit), choosing between groupBy and groupingBy().eachCount(), extra passes over the data, and the laziness of Sequence without a terminal step like toList(). At the end, there is a checklist of common mistakes that break reports and statistics.

We break down how, in Kotlin, to assemble “related” reports for a console expense tracker: we fix the data format ( List<Pair<String, Int>>), make a shared category-normalization step via trim() and lowercase(), separate calculation from output, and then implement the total, byCategory, threshold, and top reports based on fold, groupBy, sorting, and filtering.