my paper cuts with rustfmt - and what to do about them

Wed, 24 Jun 2026 15:26:22 +0200

rustfmt occasionally fails me. Of cause, the examples are somewhat taken from production code, but with all identifiers rendered unrecognizable and all strings replaced by random words. Unhelpful comments to all of this would be “why don’t you use shorter identifiers?” or “use shorter error messages”. But let’s face it:

Naming is hard. And if your foo function and your bar function both return a “result”, but neither can use the std::result::Result (slightly different semantics, non-binary logic, …) and you can’t introduce a common result type (too different needs for a one-size-fits-all, not even with type parameters), then you have to end up with a type name that says “result” with some more context. And a reader 10 levels up the call tree must not confuse the FooResult with the BarResult. Taking a thesaurus to come up with different names would be counter productive. Between a MyResult and MyOutcome, a human reader won’t remember which one is from foo and which one is from bar, what the API differences are, etc. The best name migh just be foo_module::Result and bar_module::Result and use foo_module::Result won’t help the reader.
I suck at naming. That must not be a justification for using poor names, but … should I really spend another week on trying to come up with a better name and then eventually not come up with one? A reviewer might anyways have a different perspective and I could highlight a name with a few suggestions. But at that point in time, I need formatting. (And let’s keep in mind that reviewer time and energy are a finite resource)
Same with the strings. By now, I hate “no such file or directory” with a passion. Was this a cp call? Does the source file not exist? Does the target file not exist? … Oh, /usr/bin/cp might not exist! You know what, that’s not even the actual error that you’re investigating. The cp call was opportunistic “copy the file if it exists, if not that’s fine.” The libc author can’t know why cp is trying to access a file. The cp author doesn’t know why you’re trying to copy a file. The tool that’s invoking cp might have some context, but it now tries to read its config file to look up error handling and the config file doesn’t exist. The config file reader doesn’t know that falling back to defaults is desired. What I’m saying: With enough layers of indirection, you don’t have a complete picture, but you need to do all you can to provide the debugging person enough information. They have no idea that deep down there’s a cp invocation. It’s not enough for them to be told that cp is failing, they need information about why it’s called what is even happening, maybe a comment that “chances are high that this error message is a red herring”. I’m not an expert on logging, but with enough experience to know that cutting strings down to 25 characters isn’t a solution, either.
Line length limits are still around and somewhat justified. Once you view a git diff on the web (gitlab, github, codeberg, …), any language support of your editor won’t help. You may or may not be able to enable or disable line wrapping. At some point function(argument1, argument2) must be wrapped one argument per line.

Coding on Yet another blog restart

my paper cuts with rustfmt - and what to do about them