Objective-C Xcode compilation warning

Objective-C Xcode compilation warning

A programmer with exercises cares about the warning of his own code, just like a dead cockroach on the side of the rice bowl.-- @ Onevcat

Compilation warning

Now the compiler is sometimes very noisy, and the warning given by the compiler is very useful to developers. The warning will not stop compilation and linking, nor cause the program to be unable to run, but many times the compiler will first discover the problem, especially for Objective-C. Clang not only provides warnings for obvious errors, such as a method or interface that is not implemented, but also prompts many potential problems, such as method obsolete or problematic conversion ), in many cases, these problems may become potential fatal errors and must be taken seriously.

Dynamic languages such as Ruby and PHP do not have the so-called compilation warning, while many of the warnings in C # or Java are discarded methods that have to be taken care, many developers are used to ignore warnings for development. OC is now maintained by Apple, and Clang's LLVM is also being implemented by Apple. It can be said that the entire process from language to compiler to SDK is in progress, therefore, warnings during OC development are often more useful than warnings in other languages. Enable as many warning prompts as possible and avoid generating warnings as much as possible during program development. This is required for building a robust and efficient program.

Enable additional warning in Xcode

The Xcode Project template has enabled some default and common warning prompts for our settings. These default settings are designed to be compatible with some projects of the previous year and are not opened much, only warnings are given to the most dangerous and common parts. This is not enough for a new project. At least it is not enough for me, the first thing to do is to open as many warnings as possible.

The simplest way is to open the warning through the UI. In Xcode, the Build Setting option reserves some enable warnings for us. Find and directly select the corresponding options to enable warnings. In most of the time, the option itself is sufficient to describe the role of the warning and generate the warning time. If you do not understand it clearly, you can provide more details in the Quick Help panel on the right. Warnings specific to OC development areApple LLVM compiler 4.2 - Warnings - Objective CIn the column, whether you decide to open them or not, it is worthwhile to take a look at them, because they are the most avoided when writing OC programs. OthersApple LLVM compiler 4.2 - Warnings - …(All Versions ages and C ++) also contains a large number of options to facilitate control the generation of warnings.

Of course, it is simple to click activation warning one by one in the UI, but it is not interesting to do so every time, especially when you know what they are and decide to open them. Add the appropriate flag in the compilation option to enable or disable it. Warning: add the shape to Other C Flags in Build Setting.-W.... You can enter any number-W...To switch some warnings. For example, enter-Wall -Wno-unused-variableThe "all" warning is not all, but a majority of serious warnings), but the "unused variables" warning is not enabled. Use-W...In the UI, rather than selecting the UI, a major benefit is that when the compiler version is updated, the newly added warning is-WallIf you do not need to modify the project, the new warning will take effect. In this way, you can immediately notice the potential risks of the same project when the compiler version is updated. Another more important reason is that the Xcode UI does not provide all the warnings ==||| ..

As mentioned earlier, note that,-WallAlthough the name is all, it is really just a confusing word. In fact-WallOnly one subset of all warnings is covered. On StackExchange, a Clang developer working on Google answered the question, explaining some important warning groups:

• -Wall andNoAll warnings. This warning group is used by compiler developers to warn highly confident about the proposition "there is a problem with your code. If there is a warning in your code under this set, it is basically that your code has serious problems. But at the same time, it doesn't mean that everything is fine when you open Wall. Because Wall only targets a few problems in the classic code library, some fatal warnings cannot be captured by it. However, whatever the case, because Wall warnings provide credibility and high priority warnings, it should be a good habit to open this group of warnings for at least all new projects for all projects.
• -Wextra as its name,-WextraThe Group provides an "additional" Warning. This group and-WallGroups are almost equally useful, but in some cases code is too strict. A common example is,-WextraContains-Wsign-compareThis warning identifier checks the type of signed and unsigned during comparison. When both sides of the comparison operator are signed and unsigned, a warning is generated. In fact, many codes do not particularly care about such comparisons. In most cases, comparing signed and unsigned is not a big problem. Of course, there will be fatal errors ). Need to note,-WextraAnd-WallThey are two independent warning groups. Although some of the warning identifiers opened in them are duplicated, they do not have a contained relationship. To use it at the same time, you must add
• -Weverything: All real warnings. However, developers generally do not choose to use this identifier because it contains warning prompts for bugs that may still exist in development. This identifier is generally used by compiler developers for debugging. If you want to enable it in your project, the warning will surely burst and you want to hit the wall ..

For instructions on which warnings are enabled for a group, refer to the GCC manual. Although Apple now uses LLVM, this part of content should inherit the GCC settings.

Control warning, partial addition or closure

Clang provides our own methods to add or temporarily disable warnings.

Force a warning:

 
 

  
  
//Generate a warning 
  
  
#pragma message "Warning 1" 
  
  
 
  
  
//Another way to generate a warning 
  
  
#warning "Warning 2" 
 
 

The two methods of force warning 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 method, replace warning with error to force the compilation to fail. For example, when publishing a class library that requires an API Key, you can use this method to prompt other developers not to forget to enter necessary information.

 
 

  
  
//Generate an error to fail the build. 
  
  
#error "Something wrong" 
 
 

If you want to disable a warning globally, write-Wno -... for example,-Wextra-Wno-sign-compare is a common combination. If the warning is enabled or disabled for a few files, add the corresponding compilation identifier to the file corresponding to the Compile Source of Build Phases. If you only want to disable a warning in a few lines, you can temporarily change the diagnostic compilation flag to suppress the warning of the specified type, as shown below:

 
 

  
  
#pragma clang diagnostic push 
  
  
#pragma clang diagnostic ignored "-Wunused-variable" 
  
  
 
  
  
int a; 
  
  
 
  
  
#pragma clang diagnostic pop 
 
 

If a is not used after a, no warning will be given for unused variables. You can view the names of the warning types you want to suppress in the build log after the warning is generated by build. In Xcode, press the shortcut key Cmd + 7 and click the latest build log to go to the details page.

What warnings should I enable?

Personal preferences, code cleanup) different, there will be different needs. My suggestion is to first enable-WallAnd-WextraBuild the project on this basis and avoid all warnings. If you encounter some problems that cannot be solved during the development process or are sure that your practice is correct, your practice is generally not wrong, is not so correct), you can selectively close some warnings. In general, the closed warning item should not exceed the number that can be counted by one hand, otherwise there must be something wrong ..

Whether to make warning equal to error

A common practice and code cleanliness is to mark warnings as errors and interrupt the compilation process. This forces developers to fix these warnings to keep the code clean and tidy. In Xcode, you can select the appropriate Treat Warnings as Errors to enable or add-WerrorMark. I personally do not like this setting because it always interrupts the development process. In many cases, it is not possible to compile and debug all the Code. On the contrary, I prefer to compile and run the code to check the results. It is not surprising that a warning will appear during the debugging compilation process. In addition, a large number of normal warnings may occur during TDD development. If there is a warning that compilation is not allowed, the development efficiency will be compromised. A good practice is to treat the warning as an error only during Release Build, because Xcode can specify the identifiers for Debug and Release separately, so this is easy to do.

In addition, some warnings can be considered as errors,-Werror=...You can also-WerrorUsed when activated-Wno-error=...To prevent some warnings from being errors. Using these compilation identifiers can achieve good control.