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.
Conversation
“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
The thing is we need words for both errors and warnings that have the same relative connotations *and* are short. I think I'd use a single char if possible, going for a pictogram instead.
2
2
Yeah, succinctness is good as you want people to focus on the content of the message/diagnostic, not the stuff surrounding it. Something about 'hierarchy of information' is involved here I think… 🤔