5 ms·

I've gotten used to seeing walls of warnings/messages when compiling things from source. It's almost a case of boy-who-cried-wolf at this point. You get lots o

I've gotten used to seeing walls of warnings/messages when compiling things from source. It's almost a case of boy-who-cried-wolf at this point. You get lots of warnings, but it works! And they're not always due to the programmer being negligent. I've had many cases where something compiles cleanly on one box, but throws warnings on another because of a slightly different version of a compiler or library. When I compile something and it runs through the entire process with not a single warning, it's truly a "...whoa" moment.

ryandrake 10y ago
Wow. When I worked as a developer, one thing I would always insist on (or push for when I was not senior enough to insist on things) was -Wall and -Werror. If your code has a warning, there is a reason for it and you should address it. Sometimes the warning is benign, so you address it with a thoughtful comment to the effect of "silence X warning - it's not a factor because Y". But at least address them! Reasons to be so anal on warnings: 1. Broken windows theory. A code base full of warnings signals that nobody cares about anything. People will get better about finding and caring about the big things when they are forced to also care about the little things. 2. When your project has a "wall of warnings" there are real bugs hiding in there. I guarantee it and would bet money on it. Here's your opportunity to fix them and you don't even need QA to point them out. Your compiler is literally telling you. 3. When things compile on one box but not another, that's a big red flag that you have something platform-specific or library version-specific that WILL bite you some time later. unsigned-signed and sizeof(int) mismatches are good examples of this. The whole "it compiles and works therefore it's done" mentality is some serious "second-year programming class" level shit, but it's everywhere. Good projects, where people care and have disciplined attitudes, discourage it.
- fao_ 10y ago
  I would probably add `-std=<lowest compatible version> -pedantic-errors` to that as well. Aside from that I agree totally.
- dmm 10y ago
  Adding -Werror to your build system sucks because future compilers implement new warnings making it very difficult to recreate new builds with new compilers, for instance when bisecting a bug. Add it to your local build with "./configure CFLAGS=-Werror" or similar? That's great!
  - nomel 10y ago
    Oh, that's interesting. What would be the method for handling this? Branch a known good commit, fix the warning, rebase everything from the future, then bisect?
  - astrange 10y ago
    Also, no team below you can ever use -Wdeprecated, and no compiler team can ever test your project with a new compiler, because all of it will break your build.
    - doubleplaid 10y ago
      Deprecation annotations are incredibly helpful, many thanks. This is off the top of my head and likely clang specific: -Werror // Treat all warnings as errors -Wno-error=deprecated // Except deprecated warnings -Wno-error=deprecated-implementation // And these ones too The deprecated-implementation warning flag should likely be made part of the deprecated warning group, but it's not yet. See the clang source for a helpful TODO? comment. -Wclang-please-warn-about-warning-groups-that-are-missing-warnings ?
- doubleplaid 10y ago
  Consider adding -Wextra. It adds a lot of warnings that will likely be bugs, but may throw more false positives than -Wall. If you are willing to put up with more false positives and/or are willing to disable certain warnings, consider -Weverything.

ryandrake 10y ago

Wow. When I worked as a developer, one thing I would always insist on (or push for when I was not senior enough to insist on things) was -Wall and -Werror. If your code has a warning, there is a reason for it and you should address it. Sometimes the warning is benign, so you address it with a thoughtful comment to the effect of "silence X warning - it's not a factor because Y". But at least address them! Reasons to be so anal on warnings: 1. Broken windows theory. A code base full of warnings signals that nobody cares about anything. People will get better about finding and caring about the big things when they are forced to also care about the little things. 2. When your project has a "wall of warnings" there are real bugs hiding in there. I guarantee it and would bet money on it. Here's your opportunity to fix them and you don't even need QA to point them out. Your compiler is literally telling you. 3. When things compile on one box but not another, that's a big red flag that you have something platform-specific or library version-specific that WILL bite you some time later. unsigned-signed and sizeof(int) mismatches are good examples of this. The whole "it compiles and works therefore it's done" mentality is some serious "second-year programming class" level shit, but it's everywhere. Good projects, where people care and have disciplined attitudes, discourage it.

fao_ 10y ago
I would probably add `-std=<lowest compatible version> -pedantic-errors` to that as well. Aside from that I agree totally.
dmm 10y ago
Adding -Werror to your build system sucks because future compilers implement new warnings making it very difficult to recreate new builds with new compilers, for instance when bisecting a bug. Add it to your local build with "./configure CFLAGS=-Werror" or similar? That's great!
- nomel 10y ago
  Oh, that's interesting. What would be the method for handling this? Branch a known good commit, fix the warning, rebase everything from the future, then bisect?
- astrange 10y ago
  Also, no team below you can ever use -Wdeprecated, and no compiler team can ever test your project with a new compiler, because all of it will break your build.
  - doubleplaid 10y ago
    Deprecation annotations are incredibly helpful, many thanks. This is off the top of my head and likely clang specific: -Werror // Treat all warnings as errors -Wno-error=deprecated // Except deprecated warnings -Wno-error=deprecated-implementation // And these ones too The deprecated-implementation warning flag should likely be made part of the deprecated warning group, but it's not yet. See the clang source for a helpful TODO? comment. -Wclang-please-warn-about-warning-groups-that-are-missing-warnings ?
doubleplaid 10y ago
Consider adding -Wextra. It adds a lot of warnings that will likely be bugs, but may throw more false positives than -Wall. If you are willing to put up with more false positives and/or are willing to disable certain warnings, consider -Weverything.