What is your approach to warnings in a project?

Skie2012-12-26 01:23:51

iOS

Skie, 2012-12-26 01:23:51

Not so long ago, my colleague and I had a small holivar on the topic of approach to warnings (warnings) in the project.
One approach to treating warnings as errors is " treat warnings as errors ".
+ project with warnings will not compile. They will need to be corrected first. Therefore, there will be fewer potential problems in the code. In the context of Objective-C, this is especially true.
- when using 3rd party libraries, there is a high probability that there will be a certain number of warnings, which you should not touch.
Another approach is to use warnings for your own needs (for example, instead of TODO or as some kind of reminder) with the #warning xxxxx.
+ you can leave an active reminder to do something or change in the code that everyone will see during compilation.
- abuse of such an approach will eventually lead to subconscious ignoring of warnings. It's also easy to overlook a real compiler warning among your own, which can sometimes lead to all sorts of problems in the application.
I would like to hear your opinion / advice / approaches on this topic.
Also a small poll in the topic;)

Answer the question

In order to leave comments, you need to log in

7 answer(s)

TheHorse, 2012-12-26
@TheHorse

As you know, mistakes are the more expensive to correct, the longer they live. Warnings are specifically designed to alert you to defects that can lead to errors. They need to be corrected immediately, and it is not difficult.
Certain types of warnings can simply be turned off if you think they are misleading you. It can and should be disabled for third-party libraries.
Using warnings to remind TODO, I think, should be done when this TODO should be implemented soon, has priority critical. You shouldn't run for a month.
Eventually. There should be no warnings in the project, and they must be removed immediately:
* fix the defect
* Disable warning classes, third-party warnings.
* Implement what they say if it's TODO.
PS In fact, everything you wrote is logical and not mutually exclusive. There is not one thing to choose, but all to use, wisely.

Rowdy Ro, 2012-12-26
@rowdyro

In C++ projects I always include treat warnings as errors. I don’t see the point of going there at the compilation stage: if the project is large, these warnings can run away quickly during assembly and the exhaust from them is 0. In addition, when updating gcc, breaking off at the warning can be very useful, up to detecting a leak.
I implement it through code comments -> doxygen -> profit.

Pilot34, 2012-12-30
@Pilot34

I put #warning for important things that need to be fixed before releasing to the app store. For example, if debug printing is enabled or if there is a test server URL that needs to be switched to production.

MikhailEdoshin, 2012-12-26
@MikhailEdoshin

I try to get rid of warnings, although I do not include an option in the compiler. Of course, I don’t include it for third-party libraries either - this is the business of their authors. Writing TODO in code, in my opinion, is not the best idea - even if this is my personal project, it is better to add a separate file with a list of tasks.

ixSci, 2012-12-26
@ixSci

Treat warnings as errors is always enabled. I shield third-party libraries from generating warnings. C++.

egorinsk, 2012-12-26
@egorinsk

But why use crookedly written libraries? If their authors ignore compiler warnings, who knows what else is out there?

Eddy_Em, 2012-12-27
@Eddy_Em

Always -Wall to not miss anything and -Werror to not want to leave the error unfixed.