When trying to output information for debugging purpose, don’t use println and such functions. Instead use macros provided by the log crate. Make sure to take advantage of the various levels of logging (info, error…).
Code should not be pushed directly to master. Changes should be submitted as merge requests.
Trivial merge requests can be merged immediately. Anything non trivial needs to wait until either:
one reviewer has carefully checked the changes and approves them, and 48hrs have passed
two reviewers have carefully checked the changes and approve them
If a merge request makes visible UI changes, include screenshots (or a screencast, if it's a more dynamic feature) in the description.
Use a type constructor that returns an empty value instead of creating a new value from another empty value. For example, that means to write String::new() instead of String::from("").
Use .unwrap_or_default() for Option and Result over unwrap_or(neutral_value). It won't work if the contained type doesn't implement the Default trait.
Prefer to process the contained value in an Option or Result with combinators and unwrap at the end, unless it makes the code difficult to read because of doing it that way.
Don't be afraid to go beyond the simpler types or even create new ones. They give semantic meaning to values and thus let the compiler check for the correctness of the code at that level if used appropriately.
AppOp is a legacy struct which shouldn't be used anymore in new code, we work on removing it.
In fractal-gtk we depend on gtk and glib, try to use glib methods to solve problems where ever possible.