-Werror is fine as something you enable in your personal development process to make sure you didn't miss a warning. But other than that, it is a bad idea. Co

-Werror is fine as something you enable in your personal development process to make sure you didn't miss a warning. But other than that, it is a bad idea. Compiler warnings are just another static analyzer, on equal footing with cppcheck, clang-tidy, etc... It is just convenient because it is built-in. So you can make a policy that in order to push something, it has to pass a variety of automatic checks including compiler warnings, static analysis, unit tests, documentation, coverage, etc... And -Werror can be used for that, though I think it would be better to let the compilation go though to make a complete report. The big problem with -Werror is that what a compiler considers a warning depends on the version of the compiler. It means you will get new warnings as you upgrade the compiler, so you will be tempted to stay with the old compiler to silence the new warnings, because otherwise, your code stops compiling. Terrible idea. Another con that is not mentioned is a typical problem when you have strict rules you can't ignore. People will do what it takes to make the warning disappear without actually solving the problem. For example, there is a warning if an enum value is not referenced in a switch/case with no default. It is a very useful warning, it tells you that some case is not implemented, and IMHO, you should leave the warning until it is properly done. But let's say you need to move forward and that annoying -Werror won't let you. You just need to add and empty default case, silencing the warning, not fixing the problem, forgetting it, and shipping buggy code. And maybe you won't do these ugly hacks (really?) but someone else will, I've seen such things done in certified code, the kind that flies airplanes...