[Technical translation] building a modern Objective-C (ii)

Structuring Modern Objective-C Translator: Ley, Dai cangshu

# Import Statement Group

We have encountered this from time to time. How many times have you written a (maybe) long implementation file, with dozens or even 20 # The import statements stacked at the beginning? Thank you. It doesn't matter! Let's help solve the problem.

# Whether the order of import is important remains controversial, so we will not mention it first. Make sure that you wantGroup. Add comments to each group.

 <QuartzCore data-preserve-html-node=/QuartzCore.h>    

Don't wait until it's time to clean up again-start now! It will be easy to add code in later, and keep your code clean.

Do not use # define to define constants.

This is a storm. But the key to constants is, well, they areRegularQuantity. The name and value remain unchanged. When you # define a constant, it will be defined in every other file that the compiler checks until # undef (if any) is encountered ). Er. This is not like a constant at all, but something like a global variable.

Do not do this.

Instead, put constants in the header file.StatementIs the extern variable, which is also defined in the implementation file.

In the header file:

  CGFloat ASHHeaderViewHeight;

Then, in implementation,

 CGFloat ASHHeaderViewHeight = ;

Now your constants can be visible to anyone who needs them (they only need the # import header file), but not to other parts of the program. It cannot be # undef, and define again elsewhere (obviously bad code taste ).

Note: Michael pointed out that, strictly speaking, we should use FOUNDATION_EXPORT to replace extern.

Name constants reasonably

I don't care whether the prefix you add to a constant is 'k', the class name, or a random prefix.Ensure. Descriptive information is required. Otherwise, as your code library grows larger, naming conflicts may occur sooner or later. Believe me in this.

Structuring Modern Objective-C Translator: Ley, Dai cangshu