Talk about Objective-c's warning (turn)

Original address: http://onevcat.com/2013/05/talk-about-warning/


A moral integrity programmer cares about the warning of his code, just like a dead cockroach on the edge of a job. --@onevcat

Attention to compilation warnings


The compiler can now be noisy, and the warnings given by the compiler are useful information for developers. Warnings do not prevent continued compilation and linking, and do not cause programs to run, but many times the compiler will first discover the problem, especially for objective-c. Clang not only warns of obvious errors (such as a method or interface), but also hints at a number of potential problems (such as obsolete methods or problematic conversions), which can become potentially fatal errors in many cases and must be taken seriously.


Dynamic languages like Ruby or PHP do not have the so-called compile warnings, and many of the warnings in C # or Java languages are obsolete methods that have to be taken care of, and many developers are accustomed to ignoring warnings for development. OC because now by Apple is responsible for maintenance, Clang's LLVM also is Apple is doing, can say from language to compiler to the SDK is in control of the whole, so the warning that do OC development is more useful than other language warning. Opening as many warning prompts as possible and avoiding generating warnings in program development is necessary for building a robust and efficient program.


Turn on additional warning tips in Xcode


Xcode's engineering templates have set some default and common warning prompts for our settings, which are not open enough to be compatible with some of the previous year's projects, and only refer to the most dangerous and common ones. This is not enough for a new project (at least not for me), and the first thing to do under the guidance of countless predecessors is to open as many warning tips as possible.


The simplest way to do this is to open the warning through the UI. In Xcode, the Build setting option allows you to open a warning by selecting the switch that opens the alert and checking the option directly. Most of the time the option itself is enough to describe the role of the warning and the timing of the warning, if not very clear, in more detail in the Quick Help panel on the right. Specific warnings for OC development are inApple LLVM compiler 4.2 - Warnings - Objective Cone column, and whether or not you decide to open them is worth taking the time to look at, as they are the most important things to avoid when writing OC programs. Several otherApple LLVM compiler 4.2 - Warnings - …(all languages and C + +) also contain a number of options to facilitate control of warning generation.


Of course, one click in the UI to activate the warning is simple, but it's not fun to do it every time, especially if you already know what they are and decide to open them. Adding the appropriate flag to the compilation option turns the warning on or off: Add the similar compilation identifier in the other C flags in build setting-W.... You can fill in as many as you-W...like to switch some warnings, for example, fill in to-Wall -Wno-unused-variableopen the "All" warning (in fact, not all, just a large number of serious warnings), but do not enable the "not used variables" warning. One of the-W...great benefits of using the form, rather than checking it on the UI, is that when the compiler version is updated, the newly added warnings-Walldo not require any modifications to the project, and new warnings can take effect if they are included. This immediately detects the potential pitfalls of the same project due to a compiler version update. Another more important reason is that: The Xcode UI does not provide all the warning =_=| |.

Just mentioned, it is important to note that, although the name of-wallis all, it is really just a confusing word, in fact-wallcovers only a subset of all warnings. On Stackexchange, there is an answer from a clang developer working at Google explaining that there are some important warning groups:



-wall is not all warnings. This warning group is open to compiler developers who have a high level of confidence in the proposition "there is a problem in the code you wrote." If you have a warning in this set of settings, it's basically that your code really has a serious problem. But at the same time, it's not that it's all right to open wall, because wall is just a handful of the classic codebase, so there are some deadly warnings that can't be captured. However, because wall warnings provide a high level of confidence and priority warnings, it should be a good practice to open this set of warnings for all projects (at least all new projects).
-wextra as its name, the-Wextragroup provides an "extra" warning. This group-Wallis almost as useful as a group, but in some cases the code is relatively harsh. A very common example is the-Wextrainclusion of-Wsign-comparethis warning flag that turns on the comparison of type checking for signed and unsigned, which generates a warning when the signed side is unsigned on both sides of the comparator. In fact, a lot of code does not pay particular attention to such comparisons, and most of the time, the comparison of signed and unsigned is not too much of a problem (of course, do not rule out a fatal error occurs). It is important to note that-Wextra-Wallthere are two warning groups that are independent of each other, although the warning signs that are open inside are duplicated individually, but the two groups do not contain relationships. If you want to use it at the same time, you must add it to other C flags
-weverything This is really all the warnings. However, the general developer does not choose to use this identity because it contains warning hints that may still exist in the development of the bug. This logo is typically used by compiler developers for debugging, and if you want to open it in your own project, the warning will be so bursting that you want to start banging on the wall.


For a description of which warnings are turned on for a group, there is a reference in the GCC manual. Although Apple is now using LLVM, this part of the content should be inherited from the GCC settings.


Control warning, local join or close


Clang provides our own way of adding warnings or temporarily shutting down warnings.


Force a warning to join:

Generate a WARNING#PRAGMA message "Warning 1"//another to Generate a warning#warning "Warning 2"

The two methods of enforcing warnings are the same for visual effects, but the warning types are slightly different, one is-W#pragma-messages, the other is-W#warnings. For the second notation, replace the warning with an error, which forces the compilation to fail. For example, when publishing a class library that requires API key, you can use this method to prompt other developers not to forget to enter the necessary information.

Generate an error to fail the build. #error "Something Wrong"

For closing a warning, if you need to close it globally, write it directly in other C flags-Wno-..., such as-Wextra -Wno-sign-comparea common combination. If a warning is turned on or off relative to a few files, the corresponding compilation identifier is added to the corresponding file in the compile source of build phases. If you just want to turn off a warning on a few lines, you can suppress a warning of a specified type by temporarily changing the diagnostic compilation tag, as follows:

#pragma clang diagnostic push#pragma clang diagnostic ignored "-wunused-variable" int A; #pragma clang diagnostic pop

If a is not used after a, there is no warning that the variable is not used. For the identity name of the type of warning you want to suppress, you can see it in the build log after build generates the warning. In Xcode, the shortcut key cmd+7 and then click on the nearest build log to go to the details to see it.


Which warning tips should I turn on


Personal preferences (code cleanliness) different, there will be different needs. My advice is for all projects, especially newly opened projects, first open-Walland-Wextrathen build the project on this basis and avoid all warnings. If you encounter something that is really impossible to resolve during development, or if you are sure that you are doing the right thing (in this case, your practice is generally not as correct if it is not the wrong one), you can selectively turn off certain warnings. In general, closed warning items should not exceed the number of a hand can be counted, otherwise there must be something wrong.


Do you want to make the warning equal to error


A common practice and code cleanliness is to identify warnings as errors, thus interrupting the compilation process. This allows developers to fix the warnings, keeping the code clean and tidy. In Xcode, you can turn it on by ticking the appropriate treat Warnings as errors, or join the-Werrorlogo. Personally, I don't like to use this setting because it interrupts the development process. Many times it is not possible to complete the code and then compile debugging, on the contrary, I prefer to write a little bit to compile and run a look at the results, so in the middle of debug when the compiler will appear warning is not surprising. In addition, if you do TDD development, there may be a large number of normal warnings, if there is a warning to not compile, development efficiency may be compromised. It is a good practice to treat warnings as errors only in the release build, because in Xcode it is possible to specify the identities for debug and release separately, so this is easy to do.


It is also possible to use certain warnings as errors, or,-Werror=...Similarly, to be-Werrorused when activated-Wno-error=...to make certain warnings not errors. The combination of these compilation identifiers provides good control.


Talk about Objective-c's warning (go)