3 ms·
I know post is about C/C++ compilers, but in general, I find it useful to treat compiler messages just as a normal log of a program – which, in this case happen
by divan 7y ago
I know post is about C/C++ compilers, but in general, I find it useful to treat compiler messages just as a normal log of a program – which, in this case happened to be a parser/compiler/linker.
Logging, in a nutshell, is a computer program seeking an attention of a human being.
When everything goes smoothly and as expected, no log output needed.
We usually have, though, 4 most often used levels of logging:
- [DEBUG] – human explicitly asking program to tell a lot, for debugging
- [INFO] - program tells "hey, I'm fine here", mostly for assuring worrying human if program even works. As confidence grows, need in this log level falls. (Historically, this log level is often abused for metrics/tracing purposes, but that's another story)
- [WARNING] - program says "hey, human I don't know if this is good or bad, up to you to decide"
- [ERROR] - human attention required, program don't know how to handle situation automatically
Now, from this perspective, [WARNING] level of the compiler is basically compiler/spec giving up on telling human what's right and what's wrong. Given the compilers are written by people who know language spec better than anyone, it would safe to assume that compiler should know better than average developer what's good and what's not.
So when compiler tells develeoper "warning: I don't know if it's ok, deal it yourself", majority of the developers can only say "meh, I don't know either" and "doesn't crash, so we're good, ignore it".
That's why I strongly believe there should be no warnings in compilers at all. INFO and ERROR levels are sufficient for this kind of programs.
- divan 7y agoAny particular reason of downvoting without explaining what's wrong with my point of view? This approach (no warning from compiler) is successfully used in Go, for example, and, I believe, the reasoning is similar.