---
title: "13.x Chapter 13 summary and quiz"
description: "Review of modules, paths, visibility, splitting code into files, crates, Cargo, and documentation, with a chapter quiz and a small organizational exercise."
url: "https://learnrust.net/chapter-13/chapter-13-summary-and-quiz/"
last_updated: "2026-06-13"
---

# 13.x Chapter 13 summary and quiz

This chapter was about organization rather than new language features, and it quietly retired an entire C++ chapter's worth of ceremony. Review, then a quiz.

## Quick review

As programs grow, names collide ([13.1](https://learnrust.net/chapter-13/naming-collisions-and-modules/)), and **modules** are named scopes that prevent it: a struct groups related values, a module groups related code. You define modules with `mod`, nest them into a tree rooted at `crate`, and name items with **paths** ([13.2](https://learnrust.net/chapter-13/defining-modules/)): absolute from `crate::`, relative from the current module or via `self::`/`super::`. `use` brings a path into scope to shorten it (the convention: import a function's parent module, but import types directly), and `as` renames to dodge collisions.

Everything is **private by default** ([13.3](https://learnrust.net/chapter-13/visibility-pub/)); `pub` exposes an item to its parent, `pub(crate)` exposes it within your crate but not to external users, and struct fields are made public one at a time. Private-by-default plus per-field visibility is **encapsulation**: expose a deliberate surface, hide the internals so you can change them freely. Moving a module to its own file is one `mod foo;` declaration plus a `foo.rs` file ([13.4](https://learnrust.net/chapter-13/splitting-code-into-files/)); nested modules become directories. This single mechanism replaces C++'s headers, header guards, forward declarations, and preprocessor includes, because `mod` names a module rather than pasting text.

A **crate** is a compile unit; a **package** (from `cargo new`) holds one or more crates ([13.5](https://learnrust.net/chapter-13/binary-and-library-crates/)). A **binary crate** (`src/main.rs`, has `main`) compiles to an executable; a **library crate** (`src/lib.rs`, no `main`) provides code for others. Putting logic in `lib.rs` and keeping `main.rs` thin makes the logic testable and reusable, which chapter 14 depends on. **Cargo** ([13.6](https://learnrust.net/chapter-13/cargo-in-depth/)) reads `Cargo.toml`, builds with `dev`/`release` profiles, and offers `check`, `test`, `doc`, `fmt`, and `clippy` beyond `run`/`build`; workspaces and features exist for larger projects. Finally, **doc comments** (`///` for the item below, `//!` for the enclosing item) build a docs site with `cargo doc` and run their examples as tests ([13.7](https://learnrust.net/chapter-13/documentation-comments/)), and the matching skill is **reading** docs ([13.8](https://learnrust.net/chapter-13/reading-documentation/)): a signature is a contract you can read, telling you what a function needs, returns, and whether it can fail.

## Quiz time

**Question #1**

What's the difference between an absolute path and a relative path, and what keyword starts each?

<details class="solution">
<summary>Show solution</summary>

An absolute path names an item starting from the crate root and begins with `crate::`. A relative path starts from the current module: just the child's name, or `self::` (current module) or `super::` (parent module). Both name the same item by walking the module tree from different starting points.

</details>

**Question #2**

This is refused. Name the error and give two fixes.

```rust
mod math {
    fn square(n: i32) -> i32 { n * n }
}

fn main() {
    println!("{}", math::square(5));
}
```

<details class="solution">
<summary>Show solution</summary>

E0603: `square` is private to `math`, so `main` can't call it. Fix (1): mark it `pub fn square`. Fix (2): if `square` should stay internal, move the calling code inside `math`, or expose a different `pub` function that calls `square`. The cleanest fix here is `pub fn square`.

</details>

**Question #3**

You have a growing `main.rs` with an inline `mod parser { ... }` and an inline `mod formatter { ... }`. Describe the files you'd create to split both into their own files, and the one line each needs in `main.rs`.

<details class="solution">
<summary>Show solution</summary>

In `main.rs`, replace each module body with a declaration: `mod parser;` and `mod formatter;`. Create `src/parser.rs` with the parser module's contents and `src/formatter.rs` with the formatter's. The compiler finds each file from its `mod` line; paths and `use` in `main.rs` stay the same. Items the rest of the program calls must be `pub`.

</details>

**Question #4**

A small exercise. Sketch a library crate `geometry` with a public `shapes` module containing a public `Circle` struct (private `radius` field, a `pub fn new`, and a `pub fn area`), and a `main.rs` in the same package that creates a circle and prints its area. Show the file layout and the key `pub`/`use` decisions.

<details class="solution">
<summary>Show solution</summary>

```
geometry/
├── Cargo.toml          (name = "geometry")
├── src/
│   ├── lib.rs          declares the public module
│   ├── shapes.rs       the Circle type
│   └── main.rs         thin binary using the library
```

```rust
// src/lib.rs
pub mod shapes;
```

```rust
// src/shapes.rs
pub struct Circle {
    radius: f64,        // private: enforces use of `new`
}

impl Circle {
    pub fn new(radius: f64) -> Circle {
        Circle { radius }
    }

    pub fn area(&self) -> f64 {
        3.14159 * self.radius * self.radius
    }
}
```

```rust
// src/main.rs
use geometry::shapes::Circle;

fn main() {
    let c = Circle::new(2.0);
    println!("area: {}", c.area());
}
```

```
area: 12.56636
```

Key decisions: `lib.rs` re-exports `shapes` with `pub mod` so the binary can reach it. `Circle` and its methods are `pub`, but `radius` stays private, so outside code must go through `new` (lesson [13.3](https://learnrust.net/chapter-13/visibility-pub/)). `main.rs` reaches the type by the package name, `geometry::shapes::Circle`, because the binary is a separate crate depending on the library ([13.5](https://learnrust.net/chapter-13/binary-and-library-crates/)). All the logic lives in the library, so it's testable; `main.rs` is a thin shell.

</details>

Your code is now organized, split, and documented. Chapter 14 makes it *trustworthy*: Rust's built-in test framework, where `#[test]`, `assert_eq!`, and the `lib.rs` split from this chapter combine into testing as an everyday habit rather than an afterthought.

## Sitemap

See the full [sitemap](https://learnrust.net/sitemap.md) for all pages.