1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129
//! Document all the things!
//!
//! - **Date:** October 3, 2015
//! - **Subject:** Documentation in general, and `rustdoc` and `cargo doc` in
//! particular.
//! - [**Audio**][mp3]
//!
//! [mp3]: https://www.podtrac.com/pts/redirect.mp3/cdn.newrustacean.com/file/newrustacean/e001.mp3
//!
//! <audio style="width: 100%" title="Document all the things!" controls preload=metadata src="https://www.podtrac.com/pts/redirect.mp3/cdn.newrustacean.com/file/newrustacean/e001.mp3"></audio>
//!
//! # Notes
//! This is a mostly-empty module, and it is intended as such. Why? Well,
//! because *almost* all the sample code exists in these comments, which serve
//! as the show notes. If you listen to the episode or take a look at the
//! [source files][src], you'll see how it works!
//!
//! [src]: /src/show_notes/e001.rs.html
//!
//! The components below are included *solely* so you can see how the
//! docstrings work with each kind of thing. Make sure to click on the names of
//! the items: there is more documentation there. Again, take a look at the
//! [source][src] to see how it looks in the context of a file module.
//!
//! Note that this module-level docstring uses `//!` rather than `///`-style
//! comments. This is because this docstring is documenting the item which
//! contains it, rather than the following item. Per [Rust RFC 505][1], the
//! preferred approach is always to use the "following" form (`///`) rather than
//! the "containing" form (`//!`), except for module-level docs like these.
//! (I will be following RFC 505 throughout.)
//!
//! [1]: https://github.com/rust-lang/rfcs/blob/master/text/0505-api-comment-conventions.md
//!
//! # Links
//! - [Rust and MSVC tracking issue][2]
//! - Other documentation tools:
//! + Predecessors:
//! * [Python's Sphinx tool]
//! * [Doxygen]
//! * [`JSDoc`]
//! * [`JavaDoc`]
//! + Other new languages with Markdown tooling
//! * [Julia][7] has a [built-in documentation system][8]
//! * [Elixir][9] has [`ex_doc`][10]
//! - [Rust 1.3 release announcement][11]
//! - Rust's package hosting: [crates.io][12]
//! + [Crater][13] for testing for backwards compatibility
//! - [Semantic versioning][14]
//! + ["Stability as a Deliverable"][15]: Rust official blog post on
//! version stability, backwards compatibility, and release channels.
//! - [The Rust book chapter on `rustdoc`][16]
//!
//! [2]: https://github.com/rust-lang/rfcs/issues/1061
//! [Python's Sphinx tool]: http://sphinx-doc.org
//! [Doxygen]: http://www.stack.nl/~dimitri/doxygen/
//! [`JSDoc`]: http://usejsdoc.org
//! [`JavaDoc`]: http://www.oracle.com/technetwork/articles/java/index-jsp-135444.html
//! [7]: http://julialang.org
//! [8]: http://julia.readthedocs.org/en/latest/manual/documentation/
//! [9]: http://elixir-lang.org
//! [10]: https://github.com/elixir-lang/ex_doc
//! [11]: http://blog.rust-lang.org/2015/09/17/Rust-1.3.html
//! [12]: https://crates.io
//! [13]: https://github.com/brson/taskcluster-crater
//! [14]: http://semver.org
//! [15]: http://blog.rust-lang.org/2014/10/30/Stability.html
//! [16]: https://doc.rust-lang.org/book/second-edition/ch14-02-publishing-to-crates-io.html#making-useful-documentation-comments
//!
//! # Follow/Support
//!
//! - New Rustacean:
//! + Twitter: [@newrustacean](https://www.twitter.com/newrustacean)
//! + App.net: [@newrustacean](https://alpha.app.net/newrustacean)
//! + <a href="https://www.patreon.com/newrustacean" rel="payment">Patreon</a>
//! + Email: [hello@newrustacean.com](mailto:hello@newrustacean.com)
//! - Chris Krycho
//! + Twitter: [@chriskrycho](https://www.twitter.com/chriskrycho)
//! + App.net: [@chriskrycho](https://alpha.app.net/chriskrycho)
/// This is a sample structure, to demonstrate `rustdoc`/`cargo doc`.
///
/// All of this will be attached to the structure definition when you see it
/// live on the site. If you need to document members, you can do it inline!
///
/// It's worth taking a look at the [source] for this: you can see how private
/// and public fields are handled differently in the documentation.
///
/// [source]: /src/show_notes/e001.rs.html
pub struct TVShow {
/// Here is a string telling us what the theme song was.
pub theme: String,
/// Here is the year the show premiered.
pub year: i32,
/// Here is the director---but (s)he's rather shy and private.
director: String,
}
/// You can also document the implementation. This is usually *not* going to be
/// something you particularly need with a `struct`, because you can just
/// attach the documentation to the `struct` itself. However, it *is* the kind
/// of thing that could be useful if you are implementing a `trait`. (More on
/// that in a later episode!)
impl TVShow {
/// This documents a fairly ho-hum structure constructor.
///
/// ```ignore
/// let a_struct = TVShow::new("The Answer", 42, "Joss Whedon");
/// ```
pub fn new(theme: &str, year: i32, director: &str) -> TVShow {
TVShow {
theme: theme.to_string(),
year,
director: director.to_string(),
}
}
}
/// This documents a plain-old function.
///
/// The same basic rules apply as with functions bound to structs; the only
/// real difference is that the docs for this won't be attached to a `struct`
/// but to the module.
pub fn use_members() {
let firefly = TVShow::new("You can't take the sky from me!", 2001, "Joss Whedon");
println!(
"Firefly (come on, sing along: \"{:?}\"): {:?}/{:?}",
firefly.theme, firefly.year, firefly.director
);
}