Setting up rustfmt and clippy for yassgy
Tags: osd600
Published: 2021-11-06 06:19:53

This week we were learning about a static analysis tools, and why they are important when creating an open source project that you intend other people to work on.

The main reason you'd want to set up something like this is because you want to set a standard across your code base. For example, a code formatter can set a format standard that everybody can have by simply running a command, without having to remember about any kind of formatting rules; the program takes care of all of that.

The tools I set up for `yassgy` are [`rustfmt`](https://github.com/rust-lang/rustfmt) and [`rust-clippy`](https://github.com/rust-lang/rust-clippy).

These two tools are the tools recommend by the Rust development team, so you might view them as the official formatter and linter for Rust.

## Installation

Surprisingly, `rustfmt` did not install by default for me, so I had to install it. Luckily, since both of these tools are endorsed by the official Rust project, I simply ran the command:

```
rustup component add rustfmt
```

And I had `rustfmt` for my usage! I ran a similar command for installing clippy:

```
rustup component add clippy
```

## Setting up the formatter

The `rustfmt` formatter is very simple to set up. Since `rustfmt` integrates very nicely with `cargo` (which you may have if you installed Rust by `rustup`), then just running

```
cargo fmt
```

in your project's root folder is enough. Of course, the formatting is not happening out of nowhere; `rustfmt` is using the defaults that the majority of the Rust community has agreed to use. If you, however, do not agree with a certain default, you may change it by setting a different value in a configuration file called `rustfmt.toml`. In my case, I defined a `rustfmt.toml` all of the values I could define, mainly to be explicit of the style I prefer. In the unlikely case that the defaults were to change, I wouldn't have to worry about why the formatting of my code is changing.

After setting the formatting options, I ran the formatting tool, and I noticed that all of my files changed! G

## Setting up the linker

`clippy` was not a big deal to setup, either. Again, the main reason is that `clippy` integrates smoothly with `cargo`, so running something like:

```
cargo clippy
```

on my project's root folder was necessary to start linting my code! I found some warnings messages, but fortunately, they were only on two files, with a total of 6 warnings or so. Either way, I did not create a configuration file for `clippy` because I found all the defaults to be good for my case, and I haven't formed a strong opinion on what configurations I should set for a Rust linter.

## Integrating with Visual Studio Code

Thanks to Visual Studio Code and its support for extensions, integrating the formatter with it wasn't super difficult.

The first thing I did was to find the extension that would help me trigger a formatting of the code when saving the file. That one, of course, is the most downloaded extension for Rust tools, the [Rust extension](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust) for Visual Studio Code. After setting the extension, I created the `settings.json` to set up the default formatter for Rust files, that one being the name of the Rust extension, `rust-lang.rust`. The file looks something like this:

```json
{
    "editor.formatOnSave": true,
    "[rust]": {
        "editor.defaultFormatter": "rust-lang.rust"
    }
}
```

I didn't set the linter to every time you saved, because `clippy` would compile all of the files, which means that you would compile your program for every little change you do!

## Remarks

While this setup does add a little bit more of standardization for formatting and linting, this method is not entirely reliable. We would need to run the formatter and the linter before actually committing, so there is a chance for the programmer to forget to do so.

The way we can reliably lint the code prior committing is by running a git hook before committing, and, if the linting shows any glaring errors, then the committing would be aborted.

Because I am not sure how to create a platform-agnostic git hook, I haven't actually written it. Hopefully, I will write a future entry of me figuring this out...