Repository: paritytech/substrate
File: src/lib.rs (Rust)

Code before:
//!   Substrate's main configurability is in the runtime, the client is also highly generic and can
//!   be customized to a great extent.
//!
//! ## Structure
//!
//! Substrate is a massive cargo workspace with hundreds of crates, therefore it is useful to know
//! how to navigate its crates.
//!
//! In broad terms, it is divided into three categories:
//!
//! * `sc-*` (short for *substrate-client*) crates, located under `./client` folder. These are all
//!   the client crates. Notable examples are crates such as [`sc-network`], various consensus
//!   crates, [`sc-rpc-api`] and [`sc-client-db`], all of which are expected to reside in the client
//!   side.
//! * `sp-*` (short for *substrate-primitives*) crates, located under `./primitives` folder. These
//!   are the traits that glue the client and runtime together, but are not opinionated about what
//!   framework is using for building the runtime. Notable examples are [`sp-api`] and [`sp-io`],
//!   which form the communication bridge between the client and runtime, as explained in
//!   [`substrate_diagram`].
//! * `pallet-*` and `frame-*` crates, located under `./frame` folder. These are the crates related
//!   to FRAME. See [`frame_support`] for more information.
//!
//! ### Wasm Build
//!
//! Many of the Substrate crates, such as entire `sp-*`, need to compile to both Wasm (when a Wasm
//! runtime is being generated) and native ! (for example, when testing). To achieve this, Substrate
//! follows the convention of the Rust community, and uses a `feature = "std"` to signify that a
//!  crate is being built with the standard library, and is built for native. Otherwise, it is built
//!  for `no_std`.
//!
//! This can be summarized in `#![cfg_attr(not(feature = "std"), no_std)]`, which you can often find
//! in any Substrate-based runtime.
//!
//! Substrate-based runtimes use [`substrate-wasm-builder`] in their `build.rs` to automatically
//! build their Wasm files as a part of normal build commandsOnce built, the wasm file is placed in
//! `./target/{debug|release}/wbuild/{runtime_name}.wasm`.
//!
//! ### Binaries
//!
//! Multiple binaries are shipped with substrate, the most important of which are located in the
//! `./bin` folder.
//!
//! * [`node`] is an extensive substrate node that contains the superset of all runtime and client
//!   side features. The corresponding runtime, called [`kitchensink_runtime`] contains all of the
//!   modules that are provided with `FRAME`. This node and runtime is only used for testing.
//! * [`node-template`]: a template node that contains a minimal set of features and can act as a
//!   starting point of a project.
//! * [`subkey`]: Substrate's key management utility.
//! * [`chain-spec-builder`]: Substrate's utility to build *chain specifications*. Such
//!   specifications can then be used with `--chain` argument of a typical substrate node's CLI.
//!

Review comment (suggestion):
```suggestion
//! runtime is being generated) and native (for example, when testing). To achieve this, Substrate
```

Code after:
//!   Substrate's main configurability is in the runtime, the client is also highly generic and can
//!   be customized to a great extent.
//!
//! ## Structure
//!
//! Substrate is a massive cargo workspace with hundreds of crates, therefore it is useful to know
//! how to navigate its crates.
//!
//! In broad terms, it is divided into three categories:
//!
//! * `sc-*` (short for *substrate-client*) crates, located under `./client` folder. These are all
//!   the client crates. Notable examples are crates such as [`sc-network`], various consensus
//!   crates, [`sc-rpc-api`] and [`sc-client-db`], all of which are expected to reside in the client
//!   side.
//! * `sp-*` (short for *substrate-primitives*) crates, located under `./primitives` folder. These
//!   are the traits that glue the client and runtime together, but are not opinionated about what
//!   framework is using for building the runtime. Notable examples are [`sp-api`] and [`sp-io`],
//!   which form the communication bridge between the client and runtime, as explained in
//!   [`substrate_diagram`].
//! * `pallet-*` and `frame-*` crates, located under `./frame` folder. These are the crates related
//!   to FRAME. See [`frame_support`] for more information.
//!
//! ### Wasm Build
//!
//! Many of the Substrate crates, such as entire `sp-*`, need to compile to both Wasm (when a Wasm
//! runtime is being generated) and native (for example, when testing). To achieve this, Substrate
//! follows the convention of the Rust community, and uses a `feature = "std"` to signify that a
//!  crate is being built with the standard library, and is built for native. Otherwise, it is built
//!  for `no_std`.
//!
//! This can be summarized in `#![cfg_attr(not(feature = "std"), no_std)]`, which you can often find
//! in any Substrate-based runtime.
//!
//! Substrate-based runtimes use [`substrate-wasm-builder`] in their `build.rs` to automatically
//! build their Wasm files as a part of normal build commandsOnce built, the wasm file is placed in
//! `./target/{debug|release}/wbuild/{runtime_name}.wasm`.
//!
//! ### Binaries
//!
//! Multiple binaries are shipped with substrate, the most important of which are located in the
//! `./bin` folder.
//!
//! * [`node`] is an extensive substrate node that contains the superset of all runtime and client
//!   side features. The corresponding runtime, called [`kitchensink_runtime`] contains all of the
//!   modules that are provided with `FRAME`. This node and runtime is only used for testing and
//!   demonstration.
//!     * [`chain-spec-builder`]: Utility to build more detailed chain-specs for the aforementioned
//!       node. Other projects typically contain a `build-spec` subcommand that does the same.
//! * [`node-template`]: a template node that contains a minimal set of features and can act as a
//!   starting point of a project.
//! * [`subkey`]: Substrate's key management utility.