Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make better use of rust docs, set up doc tests, revamp user facing API function and struct documentation. #27

Open
Exiled1 opened this issue Mar 18, 2023 · 0 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@Exiled1
Copy link
Contributor

Exiled1 commented Mar 18, 2023

We should really go through and make a sweep through any user/dev facing API functions. There's a lot of documentation that's either very dated or probably just wrong.

We should make it a point to document components, whether its modules, structs, functions, macros, etc. Any public facing API should have documentation.

Here's at least a basic structure to documentation:

[short sentence explaining what it is]

[more detailed explanation]

[at least one code example that users can copy/paste to try it]

[even more advanced explanations if necessary]

Here's an example for the standard library for the std::env::args() function:

Returns the arguments which this program was started with (normally passed
via the command line).

The first element is traditionally the path of the executable, but it can be
set to arbitrary text, and may not even exist. This means this property should
not be relied upon for security purposes.

On Unix systems shell usually expands unquoted arguments with glob patterns
(such as `*` and `?`). On Windows this is not done, and such arguments are
passed as-is.

# Panics

The returned iterator will panic during iteration if any argument to the
process is not valid unicode. If this is not desired,
use the [`args_os`] function instead.

# Examples

```
use std::env;

// Prints each argument on a separate line
for argument in env::args() {
    println!("{argument}");
}
```

[`args_os`]: ./fn.args_os.html

We should also make a good effort to make it so that any code that we write that's used by someone else. An example of this using our own codebase would be for the handle_input_events() function in InputHelper struct that's currently being made:

/// Used to populate the InputHelper by grabbing the InputEvents from the inbox.
///
/// # Arguments
///
/// * `io` - A mutable reference to the engine IO manager.
///
/// # Examples
///
/// ```
/// # fn main() { handle_input_events()}
/// # fn do_stuff() {} // placeholder for doctest.
///
/// struct ClientState {
///     input_helper: InputHelper
/// }
///
/// fn update(&mut self, io: &mut EngineIo, query: &mut QueryResult) {
///     self.input_helper.handle_input_events(io);
///     // ..snip
///     for frame in io.inbox::<FrameTime>() {
///         // DeltaTime checks for input
///         if self.input_helper.key_down(KeyCode::W) {
///             do_stuff();
///         }
///     }
/// }
/// ```
pub fn handle_input_events(&mut self, io: &mut EngineIo) {
    for event in io.inbox::<InputEvent>() {
        self.update(&event);
    }
}

This isn't a perfect example and could use work, since it probably wouldn't compile as it is. However, this brings me to the next point.

Utilization of rustdoc.

There are incredible things relating to documentation within Rust, I suggest looking at this link to see what I'm talking about.

Rustdoc goes beyond just giving us neatly formatted code though. It also gives us the ability to create doctests.

This means we can support literally executing our documentation examples as tests which makes sure that our documentation is up to date and working! The code doesn't have to fully function, simply compile! Here's a link to learn about documentation tests!

This issue will probably be here for a while, or could be moved to a developer guide. You guys get the point though :) 🦀

@Masterchef365 Masterchef365 added documentation Improvements or additions to documentation enhancement New feature or request labels May 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants