You know what? I make an effort to always use plain language and try to come accross as matter of fact (playfulness might be accepted but is frowned upon) in diagnostics, but just removing the leading "error:" might actually be a small change ti reframe the interaction.
Conversation
Exactly! Doing that has led me in a direction I like, at least.
Including a “warning” or “error” prefix does serve some purposes, like helping IDEs/editors format messages that follow (or vaguely imitate) the standardish GNU format, although those tags aren’t very informative.
1
2
“Error” might be “I can’t”, or “You’ve asked me not to”, or “I will, but only if you super-promise that these shenanigans are what you meant to do”; “warning” might be about anything: style, performance, possible issues, or even *likely* issues too noisy to make errors.
1
3
Any idea what a better prefix would be? Or would it be better to just remove it? Or do we dial down the severity of this stuff in development, so you get 'info' and 'note' messages instead, leaving the errors for CI and release builds?
2
(this doesn't solve the issues you raised in the previous tweet, just wondering as somebody who makes a diagnostic reporting library, hehe 😳)
1
1
If you can break with convention, removing `error: ` is an easy win
1
2
Yeah, thinking maybe it would be good to demonstrate that in the examples and documentation. Try to nudge downstream tool-makers in the right direction I guess… ‘this is what your tool could be like’ – hehe :)
1
1
Maybe "reason:" could work as a prefix? As in "the reason compilation stopped". Otherwise "info" is probably good
1
What about "fixme: "? Thinking about this:
Quote Tweet
This is most obvious with refactoring — experienced programmers will structure a refactoring so that the type checker tells them everywhere they need to fix (whenever possible…). Those “errors” are just a checklist from a very diligent partner.
Show this thread
2
3
I think that sounds good, but it will probably depend on what the overall context is. If it's always prefaced with "Compilation could not continue" or something? And then the fixme's is what must be solved
2
Hmm yeah. Do note that I'd want the compilation to continue, plonking in a bit of code that aborted/crashed the program if the fixme if it was encountered at runtime.