Getters and setters is the one I'm most at disagreement with.
// Mine
let label = Label.text("Hello Wold");
let label_text = label.get_text();
// Theirs
let label = Label.set_text("Hello Wold");
let label_text = label.text();
Their style is pervasive in Rust, such as in the standard library, so I would personally apply a when-in-rome philosophy. FWIW something like `.text("hello")` I would expect to see in a builder-pattern but not in a setter for an object that's already built.
That being said I don't particularly understand your conception of a method. They are both methods. The getter ought to have a shorter name since it is probably called more frequently and because it inherently has less of an impact -- this goes along with the principle that names that demand attention should be larger and easier to notice.
My use case is a TUI framework (https://www.incredible.rs/). The setters configure elements in a chain-able manner. I grappled with the rust convention and decided to go the other way. Rational as mentioned.
But this made me think...
> "The getter ought to have a shorter name since it is probably called more frequently"
So i checked. Rough agent driven counts:
https://github.com/ronilan/incredible-flappy 407 setters and 183 getters.
https://github.com/ronilan/rusticon 546 setters and 5 getters
https://github.com/ronilan/shape-sorting 688 setters and 33 getters.
And in a code editor with a lot of ui configurations based on reusable elements 2865 setters and 206 getters.
In reactive apps on state handlers call on setters with state values. No getters involved...
That means those are probably builders and not setters. Do they change an existing object or a newly-constructed or to-be-constructed object?
They are setters. They modify an element after instantiation. Mostly as part of the initial build, but then also in the event closure. Under the hood, a struct with interiorly mutable fields.
Gotcha, so in your case, users of the library will set values much more often than read them (since the reading will be done by the TUI framework for display).
I think which to use in general Rust code depends on the purpose of your type.
A builder type like `Command` will have unqualified setters and `get_` qualified getters.
For record-like-structs, I think unqualified getters becomes preferred and `set_` qualified setters.
This style is aligned with protocol buffers, which is aligned with the style of protos in C++.
https://protobuf.dev/reference/rust/rust-generated/