Recommendations for enabling more compiler checks

Compilers enable by default, a set of warnings they will emit on dodgy or less-than-ideal code. These defaults:

• a. change over time
• b. vary between compiler versions
• c. do not include some of the most valuable warnings that might help prevent bugs

This issue is designed to focus on the problem of c from the perspective of the latest clang++ 4.x versions.

Enabling more warnings than compilers do by default can be an important way of catching bugs early. For example integer truncation bugs can often be detected by enabling -Wconversion, which is not on by default.

Enabling more warnings is very difficult to do after a project is big (e.g. https://github.com/Project-OSRM/osrm-backend/pull/4495 and https://github.com/mapnik/mapnik/issues/2907 and https://github.com/mapnik/mapnik/issues/3204). It is best not to wait and rather to start a project with aggressive warnings from the beginning.

So, the question then becomes: what is a good set of aggressive warnings to enable at the start of a project (or to try to integrate into existing projects)?

In particular:

1. 🍇 Which flags we should always enable for all code no matter what?

2. 🍊 What additional flags may be very useful in some scenarios/some code bases?

3. 🍏 For small projects where it is feasible, can we actually start with clang++s -Weverything? This, when feasible, might be ideal. How to do it?

4. 🍎 What compiler specific flags should we recommend (that only currently work for clang++ or g++)?

Bắt đầu bằng cách xem xét bốn câu hỏi của issue về các cảnh báo quá nghiêm ngặt trong clang++ 4.x, bao gồm -Wconversion và -Weverything. Nghiên cứu các flags nào hữu ích trong nhiều trường hợp, phụ thuộc vào kịch bản hoặc đặc thù của compiler, sau đó ghi lại một khuyến nghị rõ ràng và giải thích cách các dự án nhỏ có thể áp dụng chúng; công việc được hoàn thành khi hướng dẫn về cảnh báo trả lời cả bốn câu hỏi.