3 ms·

I tend to treat warnings as errors. (Even set up my IDE to do so). In the short run it maybe is annoying but in the long run it really pays off. (Have been bur

I tend to treat warnings as errors. (Even set up my IDE to do so). In the short run it maybe is annoying but in the long run it really pays off. (Have been burned by a huge pile of crap code base with hundreds of warnings + 64bit transition).

halosghost 11y ago
This! I religiously use clang's -Weverything -Werror. Does it mean I spend more time dealing with false-positives? yes (though honestly, not that much). Does it also mean I end up writing much better code? yes, absolutely.
- blazespin 11y ago
  It doesn't take long before you naturally write warning free code. (Which ends up making you a better coder, as well. Such a simple thing..)
  - halosghost 11y ago
    I completely agree. In general, the only warnings I get on my code anymore are ones related to how a library I use does something. In those cases, I surround those particular library calls with no-warn pragmas for that particular warning and then I go about my day. It feels so much cleaner.
  - nickpsecurity 11y ago
    I didn't use a lot of C or C++ but I agree from my limited experience. I noticed the warnings and errors kicked in when I did certain things. They aggravated or worried me. So, I figured out how to not cause them. Some of those became a habit even during my brief stints working in those languages. Same thing happens in other languages with good compilers. Won't stop lazy people from ignoring them but that says more about them than the compiler. ;)
MereInterest 11y ago
Agreed. New code shouldn't be committed unless it compiles without error. The build server should then compile with -Werror, with all relevant shame being healed on the developer who breaks the build by letting a warning through.
- ryandrake 11y ago
  Sadly, you folks seem to be the minority out there. I can't even remember how many times I've had conversations along the lines of: Me: Hey, that code generates 3 compiler warnings, and you shouldn't be casting that pointer here. Them: Oh, ok, whatever, change it if you want. Me: It's not about what I want.. the code isn't correct. It'll break on some 64-bit platforms, for instance. Them: Well, it works on our target platform, and that's the one in the spec. If the spec changes, we fix it as a change request. Me: But it just happens to work! Even a different compiler could result in different behavior. Can't we just put in a little effort up front to avoid trouble later? Them: Go for it if it bothers you so much. We have real bugs to fix. Nobody cares about hypothetical problems on systems we don't support and compilers we don't use. Me: [This is going to drive me to alcoholism]
  - blazespin 11y ago
    The biggest issue with lettings warnings go is that they pile up and you start missing the important ones that point to real bugs. I have seen that happen many many times.
  - MereInterest 11y ago
    I think that I managed to convince a group member that we should have "-Wall -Wextra -pedantic" enabled all the time. He had disabled the warnings because they annoyed him. Yesterday, we spent a large quantity of time hunting down a bug that could have been avoided entirely had "-Wreturn-type" been enabled.
- to3m 11y ago
  And at the same time, while the development team is having fun with the blame game, somebody is waiting for a build that never comes! At least do it the right way round: developer machines build with -Werror, and build PC should build without. (Selective "promotion" to errors is a good idea on top of that.) That way, it's not the end of the world if people check something in that doesn't build cleanly, because they disabled -Werror on their local copy in order to get some debugging done without having to play whack-a-mole as they did so. (Obviously, they're not supposed to do that. But ideally they wouldn't be doing any debugging in the first place, either. These things happen, and processes should be designed around that.) Not all warnings are equal, and -Werror doesn't give you any discretion. You probably want to be kept abreast of unused functions, unused variables, unused parameters, int-to-bool casts, truncation of double literals, and so on - but they're poor justifications for stopping the build. You don't need to hold the build to ransom to get it to compile without warnings. All you need to do is take the warnings out.

halosghost 11y ago

This! I religiously use clang's -Weverything -Werror. Does it mean I spend more time dealing with false-positives? yes (though honestly, not that much). Does it also mean I end up writing much better code? yes, absolutely.

blazespin 11y ago
It doesn't take long before you naturally write warning free code. (Which ends up making you a better coder, as well. Such a simple thing..)
- halosghost 11y ago
  I completely agree. In general, the only warnings I get on my code anymore are ones related to how a library I use does something. In those cases, I surround those particular library calls with no-warn pragmas for that particular warning and then I go about my day. It feels so much cleaner.
- nickpsecurity 11y ago
  I didn't use a lot of C or C++ but I agree from my limited experience. I noticed the warnings and errors kicked in when I did certain things. They aggravated or worried me. So, I figured out how to not cause them. Some of those became a habit even during my brief stints working in those languages. Same thing happens in other languages with good compilers. Won't stop lazy people from ignoring them but that says more about them than the compiler. ;)

MereInterest 11y ago

Agreed. New code shouldn't be committed unless it compiles without error. The build server should then compile with -Werror, with all relevant shame being healed on the developer who breaks the build by letting a warning through.

ryandrake 11y ago
Sadly, you folks seem to be the minority out there. I can't even remember how many times I've had conversations along the lines of: Me: Hey, that code generates 3 compiler warnings, and you shouldn't be casting that pointer here. Them: Oh, ok, whatever, change it if you want. Me: It's not about what I want.. the code isn't correct. It'll break on some 64-bit platforms, for instance. Them: Well, it works on our target platform, and that's the one in the spec. If the spec changes, we fix it as a change request. Me: But it just happens to work! Even a different compiler could result in different behavior. Can't we just put in a little effort up front to avoid trouble later? Them: Go for it if it bothers you so much. We have real bugs to fix. Nobody cares about hypothetical problems on systems we don't support and compilers we don't use. Me: [This is going to drive me to alcoholism]
- blazespin 11y ago
  The biggest issue with lettings warnings go is that they pile up and you start missing the important ones that point to real bugs. I have seen that happen many many times.
- MereInterest 11y ago
  I think that I managed to convince a group member that we should have "-Wall -Wextra -pedantic" enabled all the time. He had disabled the warnings because they annoyed him. Yesterday, we spent a large quantity of time hunting down a bug that could have been avoided entirely had "-Wreturn-type" been enabled.
to3m 11y ago
And at the same time, while the development team is having fun with the blame game, somebody is waiting for a build that never comes! At least do it the right way round: developer machines build with -Werror, and build PC should build without. (Selective "promotion" to errors is a good idea on top of that.) That way, it's not the end of the world if people check something in that doesn't build cleanly, because they disabled -Werror on their local copy in order to get some debugging done without having to play whack-a-mole as they did so. (Obviously, they're not supposed to do that. But ideally they wouldn't be doing any debugging in the first place, either. These things happen, and processes should be designed around that.) Not all warnings are equal, and -Werror doesn't give you any discretion. You probably want to be kept abreast of unused functions, unused variables, unused parameters, int-to-bool casts, truncation of double literals, and so on - but they're poor justifications for stopping the build. You don't need to hold the build to ransom to get it to compile without warnings. All you need to do is take the warnings out.