{"dataset":{"id":"00000000-0000-0000-0000-000000000016","slug":"rust-best-practices","name":"Rust best practices","description":"Source-linked guidance on Rust fundamentals from The Rust Book: ownership and borrowing, error handling with Result, pattern matching, iterators and closures, and packages, crates, and modules. Scoped to Rust; not a general programming corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Packages, crates, and modules","sourceUrl":"https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html","text":"A crate is the smallest amount of code the Rust compiler considers at a time, and it comes in two forms: a binary crate compiles to an executable and must have a main function, while a library crate has no main and defines functionality meant to be shared across projects — most of the time when Rustaceans say crate, they mean a library. The crate root is the source file the compiler starts from, and it makes up the root module of the crate. A package is a bundle of one or more crates described by a Cargo.toml; it must contain at least one crate, may hold as many binary crates as you like, but at most one library crate. cargo new creates a package with a Cargo.toml and src/main.rs, which Cargo treats by convention as the crate root of a binary crate named after the package; a src/lib.rs likewise means a library crate, and extra files under src/bin each become separate binary crates. Cargo passes the crate root files to rustc to build the library or binary. Scope: Rust. Reviewed October 4, 2026.","id":"rust-best-practices:Packages, crates, and modules","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Iterators and closures","sourceUrl":"https://doc.rust-lang.org/book/ch13-02-iterators.html","text":"Iterators handle the logic of walking a sequence of items, and in Rust they are lazy: creating one has no effect until you call a method that consumes it. All iterators implement the Iterator trait, whose only required method is next, returning one item at a time wrapped in Some and None when iteration is over; calling next changes internal state, so the iterator must be mutable and each call consumes an item. The iter method iterates over immutable references, into_iter takes ownership and returns owned values, and iter_mut iterates over mutable references. Methods that call next are consuming adaptors — sum, for example, takes ownership of the iterator, so it cannot be used afterward. Iterator adaptors such as map take a closure to apply to each item and produce a new iterator without consuming the original; because adaptors are lazy too, an unused map result only earns a warning until a consuming method like collect runs the closure and gathers the results into a collection. Scope: Rust. Reviewed October 4, 2026.","id":"rust-best-practices:Iterators and closures","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Pattern matching with match","sourceUrl":"https://doc.rust-lang.org/book/ch06-02-match.html","text":"The match construct compares a value against a series of patterns — literal values, variable names, wildcards, and more — and runs the code of the first arm that fits, like a coin-sorting machine; unlike if, the matched expression can be any type, not just a Boolean. Each arm's code is an expression whose value becomes the value of the whole match, and patterns can bind to the parts of the matched value, which is how you extract data out of enum variants such as Some(i) in an Option<T>. Matches are exhaustive: the compiler refuses to compile a match whose arms do not cover every possibility, so forgetting the None case of an Option<T> is a compile error rather than a runtime bug. For the remaining cases, end with a catch-all arm: a variable pattern that binds the value, or _ to match any value without binding it — which also avoids an unused-variable warning — and use the unit value () as the arm's code when nothing should happen. Scope: Rust. Reviewed October 4, 2026.","id":"rust-best-practices:Pattern matching with match","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Error handling with Result and Option","sourceUrl":"https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html","text":"Recoverable errors are returned as Result<T, E>, an enum with Ok(T) and Err(E) variants whose generic parameters carry the success value and the error; like Option, Result and its variants are in the prelude. Handle a Result with match on Ok and Err, refining on the error kind — for example, matching error.kind() against ErrorKind::NotFound to create a missing file while panicking on anything else. Helper methods are shorter than match: unwrap returns the Ok value or panics on Err, and expect does the same with a message you choose; in production-quality code most Rustaceans choose expect over unwrap to document why the operation is expected to succeed. To propagate, the ? operator after a Result returns the Ok value or returns the Err early from the function, converting the error via the From trait's from function into the function's error type. Koskamo editorial guidance: reach for Option when a value may simply be absent, and Result when an operation can fail with an error worth describing. Scope: Rust. Reviewed October 4, 2026.","id":"rust-best-practices:Error handling with Result and Option","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Ownership and borrowing with references","sourceUrl":"https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html","text":"References let you use a value without taking ownership of it: the & syntax creates a reference, and the action of creating one is called borrowing. Because a reference does not own the value, the value is not dropped when the reference goes out of scope, so a function taking a reference parameter never has to return the value to hand ownership back. References are immutable by default — you cannot modify something you only have a & reference to; use &mut for a mutable reference, which makes the mutation intent explicit in the signature. A mutable reference is exclusive: while one exists you can have no other references to that value, mutable or immutable, and this restriction lets Rust prevent data races at compile time. A reference's scope runs from its introduction to its last use, so non-overlapping scopes let a mutable reference follow immutable ones. The compiler also guarantees references are never dangling. The rules: at any given time, either one mutable reference or any number of immutable references, and references must always be valid. Scope: Rust. Reviewed October 4, 2026.","id":"rust-best-practices:Ownership and borrowing with references","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}