Talk about Objective-c's warning (reprint)

label:

A wary programmer will care about the warnings of his own code, just as he cares about the dead end of the rice bowl. ——@onevcat

 
Pay attention to compilation warning
Now the compiler is sometimes noisy, and the warnings given by the compiler are useful information for developers. Warnings don't stop compiling and linking, and they won't cause programs to fail, but many times the compiler will first find the problem, especially for Objective-C. Clang not only warns of obvious errors (such as a method or interface not implemented), but also prompts for many potential problems (such as methods that have been deprecated or problematic), and these problems are likely to be Being a potentially fatal mistake must be taken seriously.
 
Dynamic languages like Ruby or PHP don't have a compilation warning, and many of the warnings in languages like C# or Java are obsolete methods that have to be taken care of. Many developers are used to ignoring warnings for development. OC is now maintained by Apple. CLL's LLVM is also Apple's. It can be said that the language is from the compiler to the SDK. Therefore, warnings when doing OC development are often more reference than warnings in other languages. value. Turn on as many warnings as possible and avoid generating warnings during program development, which is necessary to build a robust and efficient program.
 
Turn on extra warnings in Xcode
Xcode's project templates have been set up with some default and common warnings for us. These default settings are not compatible with many of the previous year's projects. They only warn about the most dangerous and common parts. This is not enough for a new project (at least not enough for me), the first thing to do under the guidance of countless predecessors is to open as many warnings as possible.
 
The easiest way is to open a warning via the UI. In Xcode, the Build Setting option reserves some switches for us to open the warning. Find and directly check the corresponding option to open the warning. Most of the time, the options themselves are sufficient to describe the role of the warning and the timing of the warning. If you don't understand it, there is a more detailed description in the Quick Help panel on the right. The unique warnings for OC development are in the Apple LLVM compiler 4.2 - Warnings - Objective C column. Whether you decide to open them or not, it's worth taking the time to look at them because they are all written OC programs. The most important situation to avoid. Several other Apple LLVM compilers 4.2 - Warnings - ... (All languages and C++) also contain a number of options to facilitate control of warning generation.
 
Warning options in Xcode settings
 
Of course, one-click activation warnings in the UI are simple, but it's not fun to do this every time, especially if you already know what they are and decide to open them. Adding the appropriate flag to the compile option can turn the warning on or off: add a compilation flag like -W... in the Other C Flags in the Build Setting. You can fill in any number of -W... to switch some warnings. For example, fill in -Wall -Wno-unused-variable to open the "All" warning (not all, but a big part of the warning) But), but the warning of "unused variables" is not enabled. One of the big benefits of using the -W... form instead of the UI is that when the compiler version is updated, the newly added warnings, if included in the -Wall, do not require any modifications to the project. The warning can take effect. This immediately makes it possible to detect the hidden dangers of the same project due to the compiler version update. Another more important reason is that the Xcode UI does not provide all the warnings =_=||..
 
As mentioned earlier, it should be noted that the name of -Wall is all, but this is really just a confusing term. In fact, Wall covers only a subset of all warnings. On StackExchange, there is an answer from a Clang developer working at Google that explains some important warning groups:
 
-Wall is not all warnings. This warning group turns on warnings from compiler developers who have a high confidence in the proposition that "there is a problem with the code you're writing." If there is a warning in your code under this set of settings, then basically your code really has a serious problem. But at the same time, it doesn't mean that opening Wall is all right, because Wall is only one of the few problems in the classic code base, so there are some fatal warnings that can't be caught by it. But no matter what, because Wall's warnings provide credibility and high-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 suggests, the -Wextra group provides "extra" warnings. This group is almost as useful as the -Wall group, but in some cases the code is relatively harsh. A very common example is -Wextra contains -Wsign-compare, this warning flag will turn on the type check for signed and unsigned when comparing, and will generate a warning when both sides of the comparison are unsigned. In fact, a lot of code does not particularly care about such comparisons, and most of the time, comparing signed and unsigned is not too much problem (of course, does not rule out the case of fatal errors). It should be noted that -Wextra and -Wall are two separate warning groups, although the warning flags opened inside are individually duplicated, but the two groups do not contain the relationship. If you want to use it at the same time, you must add it to Other C Flags.
 
-Weverything This is all true warnings. But the average developer will not choose to use this flag because it contains warnings about possible bugs that are still under development. This flag is generally used by compiler developers for debugging. If you want to open it in your own project, the warning will definitely cause you to start hitting the wall..
 
-Wall and -Wextra under the 0 warning project, the performance under -Weverything can be described as horrible
 
A description of which warnings are turned on in a group is available in the GCC manual. Although Apple is using LLVM now, this part of the content should be inherited from GCC settings.
 
Control warning, partial join or close
Clang provides a way for us to add warnings or temporarily turn off warnings.
 
Force a warning:
//Generate a warning
#pragma message "Warning 1"
  
//Another way to generate a warning
#warning "Warning 2"
 
The two mandatory warning methods have the same visual effect, but the warning types are slightly different, one is -W#pragma-messages and the other is -W#warnings. For the second way, replacing warning with error can force the compilation to fail. For example, when publishing some libraries that require an 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, just write -Wno-... in Other C Flags. For example, -Wextra -Wno-sign-compare is a common combination. If the warning is turned on or off for a few files, add the corresponding build flag to the corresponding file of Compile Source in Build Phases. If you just want to turn off a warning on a few lines, you can suppress the warning of the specified type by temporarily changing the diagnostic compilation flag, as follows:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunused-variable"
  
Int a;
  
#pragma clang diagnostic pop
If a is not used afterwards, there will be no warning of unused variables. The distinguished name for the type of warning you want to suppress can be seen in the build log after the build generates the warning. In Xcode, the shortcut Cmd+7 then clicks on the latest build log and you can see it in the details.
technology sharing
The details of the warning can be found in the identifier
 
What warning tips should I turn on?
Personal preferences (code cleanliness) are different and there will be different needs. My suggestion is to open -Wall and -Wextra for all projects, especially new ones, and then build the project on this basis and avoid all warnings. If you encounter something that you really can't solve or you are sure that you are correct in the development process (in fact, your approach is generally not correct even if it is not wrong), you can selectively close it. Some warnings. In general, the closed warning item should not exceed the number that one hand can count, otherwise there must be something wrong..
 
Do you want the warning to equal the error?
A very common practice and code cleanup is to flag the warning as an error, thus interrupting the compilation process. This leaves the developer having to fix these warnings to keep the code clean and tidy. In Xcode, you can enable it by checking the corresponding Treat Warnings as Errors, or by adding the -Werror flag. I personally don't like to use this setting because it always interrupts the development process. In many cases, it is not possible to write the code and then compile and debug. On the contrary, I prefer to write a bit and compile and run to see the result, so it is not surprising that there will be warnings in the middle of the debug compilation. In addition, if you do TDD development, there may be a large number of normal warnings. If there is a warning, you will not be able to compile, and the development efficiency may be compromised. A good practice is to treat the warning as an error only in Release Build, because Xcode can specify the Debug and Release respectively, so this is easy to do.
 
In addition, you can just treat some warnings as errors, -Werror=.... Similarly, you can use -Wno-error=... when -Werror is activated to make certain warnings not an error. A good combination of these compiled flags can be used to achieve good control.