You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.OnUnix systems shell usually expands unquoted arguments with glob patterns
(such as `*` and `?`).OnWindows this is not done, and such arguments are
passedas-is.
# PanicsThe 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
```
usestd::env;// Prints each argument on a separate linefor 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();/// }/// }/// }/// ```pubfnhandle_input_events(&mutself,io:&mutEngineIo){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 :) 🦀
The text was updated successfully, but these errors were encountered:
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:
Here's an example for the standard library for the
std::env::args()
function: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 inInputHelper
struct that's currently being made: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 :) 🦀
The text was updated successfully, but these errors were encountered: