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

Introduce fmt and clippy early on as "recommended practices" #1725

Open
nyurik opened this issue Jan 18, 2024 · 2 comments
Open

Introduce fmt and clippy early on as "recommended practices" #1725

nyurik opened this issue Jan 18, 2024 · 2 comments

Comments

@nyurik
Copy link
Contributor

nyurik commented Jan 18, 2024

Having taught Rust multiple classes plus advising substantial number of projects, I noticed many, especially C++ developers undervalue the importance of cargo fmt, compiler warnings, and clippy warnings.

I think it would be good to introduce good "Rust hygiene" practices early on, and make sure to stress the importance of them.

Important points:

  • most Rust projects standardize on cargo fmt, and Rust developers expect the code to follow the same rules
  • automate fmt on save (available in both VS Code and IntelliJ)
  • don't fight cargo fmt - if unhappy with the results, insert additional variables/statements to keep code easier to read
  • don't ignore compiler warnings - they hide bugs. Use #[allow(...)] in the few edge cases.
  • use cargo clippy to improve you Rust-foo.
@djmitche
Copy link
Collaborator

This is a good idea!

We work hard to resist the urge to introduce something "early" because it's "important" -- otherwise we'd have all four days' content covered before lunch on day 1! We try to adopt a "circular" approach where things are mentioned lightly at first, and then revisited in more detail.

Note that we do mention rustfmt in the exercise in the first segment. I agree that's not enough, but that may be a good place for the first light touch -- maybe just one more sentence in the speaker notes there? We also touch on error messages throughout the course, but perhaps that could use another callout or two in the speaker notes on day 1.

We had a few other "one-off" topics that didn't warrant their own 30-minute segment. For a while those were in a sort of "miscellaneous" segment, but that was not great for students. Most of that content has now been mixed into other segments as a light-weight aside. For example, Documentation is covered in the standard-library-types segment. Maybe all of the points above could be covered in a slide in the "Testing" segment?

@nyurik
Copy link
Contributor Author

nyurik commented Jan 19, 2024

Heh, agree, prioritization is hard. I guess my concern is that most students have to be re-molded from other languages - they try to keep old habits that worked well before, but might not apply to Rust... Like using return everywhere. And if we can set up students with the right "getting started" workspace template, they will continue using the same conventions for all development.

Recently I had a long training session with a novice Rust dev after they already written a fairly large Rust project. Biggest surprises were that:

  • Unlike many other languages, Rust community has really standardized on a common format that most projects use. It's not a "we could use one of the available formatters", but rather Rust has "the formatter" (took some time to explain that most Rust devs expect this)
  • Don't fight fmt -- just modify the code a little bit and it will look even more readable
  • The importance of clippy as a Rust learning tool
  • over-abuse of the match statements (e.g. instead of using the ? with impl From<ErrorA> for ErrorB, etc)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants