> Type names should be imported and used unqualified

This just pushes people to have redundant information in types (`IoError` instead of `io::Error`).

Unless a type is widely recognized (like `HashMap`), I prefer to have them fully qualified so I have the contextual meaning for it. If I am working with a generic name like `Source`, what does that mean? I shouldn't have to look up in the imports to understand the code (or only understand it through an LSP).

Reducing imports also reduces unnecessary merge conflicts.

▲

Blikkentrekker 3 hours ago | parent | next [-]

It says below that that in cases of things like `io::Error` it should be used as that though, as in “cases of ambiguities”. It specifically speaks of not using `regex::Regex` but just `Regex` which seems more reasonable to me.

	▲	B-Con an hour ago \| parent \| next [-]
		Google's style guides tend to reduce namespace redundancy. Everyone remembers finding some hideous name like foo.widget.widgetBuilder.widgetFactory in Java or something. It's nice to have naming rules, or at least guidelines, focused on trimming redundancy and keeping the signal high.
	▲	epage 3 hours ago \| parent \| prev [-]
		That guideline is in response to an API design. I'm speaking to how the default stance (import types) feeds back into API design.

▲

wtetzner 3 hours ago | parent | prev [-]

Honestly I think having blanket rules in either direction is a bad idea. Sometimes it makes sense to qualify things, sometimes it's clearer if you don't.