Objective-C编码规范：26个方面解决iOS开发问题

最新推荐文章于 2024-05-26 20:32:16 发布
最新推荐文章于 2024-05-26 20:32:16 发布
阅读量362 收藏 1
点赞数

Objective-C编码规范：26个方面解决iOS开发问题

发表于 2015-06-02 10:32|  17894次阅读| 来源 CSDN|  34 条评论| 作者 刘耀柱
移动开发 Objective-C iOS 规范 开发规范
allowtransparency="true" frameborder="0" scrolling="no" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-06-01%2F2824818-objective-c-style-guide%2F1&type=3&count=&appkey=&title=%E8%8B%B9%E6%9E%9C%E5%85%AC%E5%8F%B8%E5%B7%B2%E7%BB%8F%E6%9C%89%E4%B8%80%E4%BB%BD%E9%9D%9E%E5%B8%B8%E5%85%A8%E9%9D%A2%E7%9A%84Objective-C%E7%BC%96%E7%A0%81%E6%8C%87%E5%8D%97%EF%BC%8CGoogle%E3%80%81GitHub%E3%80%81New%20York%20Times%E7%AD%89%E4%B9%9F%E5%9D%87%E5%8F%91%E5%B8%83%E4%BA%86%E5%85%B6iOS%E5%9B%A2%E9%98%9F%E4%BD%BF%E7%94%A8%E8%A7%84%E8%8C%83%E3%80%82%E6%9C%AC%E6%96%87%E8%AF%91%E8%80%85%E5%AF%B9raywenderlich.com%E5%9B%A2%E9%98%9F%E7%9A%84Objective-C%E7%BC%96%E7%A0%81%E9%A3%8E%E6%A0%BC%E8%A7%84%E8%8C%83%E8%BF%9B%E8%A1%8C%E4%BA%86%E7%BF%BB%E8%AF%91%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1446373701721" width="22" height="16"> 摘要：苹果公司已经有一份非常全面的Objective-C编码指南，Google、GitHub、New York Times等也均发布了其iOS团队使用规范。本文译者对raywenderlich.com团队的Objective-C编码风格规范进行了翻译。

【按语】由于我正在准备模拟开发饿了么这个App，到时可能有些iOS开发者参与进来。这时如果每个人的Objective-C编码风格都不一样，这样不易于保持代码一致性和难以Code Review。所以我在网上搜索到The official raywenderlich.com Objective-C style guide这篇关于Objective-C编码风格的文章，觉得可以作为这个项目的Objective-C的编码标准，所以就翻译这篇文章。这篇编码风格指南概括了raywenderlich.com的编码规范，可能有些删减或修改。

介绍

我们制定Objective-C编码规范的原因是我们能够在我们的书，教程和初学者工具包的代码保持优雅和一致。即使我们有很多不同的作者来完成不同的书籍。

这里编码规范有可能与你看到的其他Objective-C编码规范不同，因为它主要是为了打印和Web的易读性。

关于作者

这编码规范的创建是由很多来自raywenderlich.com团队成员在Nicholas Waynik的带领下共同完成的。团队成员有：Soheil Moayedi Azarpour、Ricardo Rendon Cepeda、Tony Dahbura、Colin Eberhardt、Matt Galloway、Greg Heo、Matthijs Hollemans、Christopher LaPollo、Saul Mora、Andy Pereira、Mic Pringle、Pietro Rea、Cesare Rocchi、Marin Todorov、Nicholas Waynik和Ray Wenderlich。

我们也非常感谢New York Times 和Robots & Pencils'Objective-C编码规范的作者。这两个编码规范为本指南的创建提供很好的起点。

背景

这里有些关于编码风格Apple官方文档，如果有些东西没有提及，可以在以下文档来查找更多细节：

语言

应该使用US英语。

应该：

[cpp]  view plain copy
  1. UIColor *myColor = [UIColor whiteColor];  

不应该：

[cpp]  view plain copy
  1. UIColor *myColour = [UIColor whiteColor];  

代码组织

在函数分组和protocol/delegate实现中使用#pragma mark -来分类方法，要遵循以下一般结构：

[cpp]  view plain copy
  1. #pragma mark - Lifecycle  
  2. - (instancetype)init {}  
  3. - (void)dealloc {}  
  4. - (void)viewDidLoad {}  
  5. - (void)viewWillAppear:(BOOL)animated {}  
  6. - (void)didReceiveMemoryWarning {}  
  7. #pragma mark - Custom Accessors  
  8. - (void)setCustomProperty:(id)value {}  
  9. - (id)customProperty {}  
  10. #pragma mark - IBActions  
  11. - (IBAction)submitData:(id)sender {}  
  12. #pragma mark - Public  
  13. - (void)publicMethod {}  
  14. #pragma mark - Private  
  15. - (void)privateMethod {}  
  16. #pragma mark - Protocol conformance  
  17. #pragma mark - UITextFieldDelegate  
  18. #pragma mark - UITableViewDataSource  
  19. #pragma mark - UITableViewDelegate  
  20. #pragma mark - NSCopying  
  21. - (id)copyWithZone:(NSZone *)zone {}  
  22. #pragma mark - NSObject  
  23. - (NSString *)description {}  

空格

  • 缩进使用4个空格，确保在Xcode偏好设置来设置。（raywenderlich.com使用2个空格）
  • 方法大括号和其他大括号(if/else/switch/while 等.)总是在同一行语句打开但在新行中关闭。

应该：

[cpp]  view plain copy
  1. if (user.isHappy) {  
  2.     //Do something  
  3. } else {  
  4.     //Do something else  
  5. }  

不应该：

[cpp]  view plain copy
  1. if (user.isHappy)  
  2. {  
  3.   //Do something  
  4. }  
  5. else {  
  6.   //Do something else  
  7. }  

  • 在方法之间应该有且只有一行，这样有利于在视觉上更清晰和更易于组织。在方法内的空白应该分离功能，但通常都抽离出来成为一个新方法。
  • 优先使用auto-synthesis。但如果有必要，@synthesize和@dynamic应该在实现中每个都声明新的一行。
  • 应该避免以冒号对齐的方式来调用方法。因为有时方法签名可能有3个以上的冒号和冒号对齐会使代码更加易读。请不要这样做，尽管冒号对齐的方法包含代码块，因为Xcode的对齐方式令它难以辨认。

应该：

[cpp]  view plain copy
  1. // blocks are easily readable  
  2. [UIView animateWithDuration:1.0 animations:^{  
  3.   // something  
  4. } completion:^(BOOL finished) {  
  5.   // something  
  6. }];  

不应该：

[cpp]  view plain copy
  1. // colon-aligning makes the block indentation hard to read  
  2. [UIView animateWithDuration:1.0  
  3.                  animations:^{  
  4.                      // something  
  5.                  }  
  6.                  completion:^(BOOL finished) {  
  7.                      // something  
  8.                  }];  

注释

当需要注释时，注释应该用来解释这段特殊代码为什么要这样做。任何被使用的注释都必须保持最新或被删除。

一般都避免使用块注释，因为代码尽可能做到自解释，只有当断断续续或几行代码时才需要注释。例外：这不应用在生成文档的注释

命名

Apple命名规则尽可能坚持，特别是与这些相关的memory management rules (NARC)。

长的，描述性的方法和变量命名是好的。

应该：

[cpp]  view plain copy
  1. UIButton *settingsButton;  

不应该：

[cpp]  view plain copy
  1. UIButton *setBut;  

三个字符前缀应该经常用在类和常量命名，但在Core Data的实体名中应被忽略。对于官方的raywenderlich.com书、初学者工具包或教程，前缀'RWT'应该被使用。

常量应该使用驼峰式命名规则，所有的单词首字母大写和加上与类名有关的前缀。

应该：

[cpp]  view plain copy
  1. static NSTimeInterval const RWTTutorialViewControllerNavigationFadeAnimationDuration = 0.3;  

不应该：

[cpp]  view plain copy
  1. static NSTimeInterval const fadetime = 1.7;  

属性也是使用驼峰式，但首单词的首字母小写。对属性使用auto-synthesis，而不是手动编写@synthesize语句，除非你有一个好的理由。

下划线

当使用属性时，实例变量应该使用self.来访问和改变。这就意味着所有属性将会视觉效果不同，因为它们前面都有self.。

但有一个特例：在初始化方法里，实例变量(例如，_variableName)应该直接被使用来避免getters/setters潜在的副作用。

局部变量不应该包含下划线。

方法

在方法签名中，应该在方法类型(-/+ 符号)之后有一个空格。在方法各个段之间应该也有一个空格(符合Apple的风格)。在参数之前应该包含一个具有描述性的关键字来描述参数。

"and"这个词的用法应该保留。它不应该用于多个参数来说明，就像initWithWidth:height以下这个例子：

应该：

[cpp]  view plain copy
  1. - (void)setExampleText:(NSString *)text image:(UIImage *)image;  
  2. - (void)sendAction:(SEL)aSelector to:(id)anObject forAllCells:(BOOL)flag;  
  3. - (id)viewWithTag:(NSInteger)tag;  
  4. - (instancetype)initWithWidth:(CGFloat)width height:(CGFloat)height;  

不应该：

[cpp]  view plain copy
  1. -(void)setT:(NSString *)text i:(UIImage *)image;  
  2. - (void)sendAction:(SEL)aSelector :(id)anObject :(BOOL)flag;  
  3. - (id)taggedView:(NSInteger)tag;  
  4. - (instancetype)initWithWidth:(CGFloat)width andHeight:(CGFloat)height;  
  5. - (instancetype)initWith:(int)width and:(int)height;  // Never do this.  

变量

变量尽量以描述性的方式来命名。单个字符的变量命名应该尽量避免，除了在for()循环。

星号表示变量是指针。例如， NSString *text 既不是 NSString* text 也不是 NSString * text，除了一些特殊情况下常量。

私有变量应该尽可能代替实例变量的使用。尽管使用实例变量是一种有效的方式，但更偏向于使用属性来保持代码一致性。

通过使用'back'属性(_variable，变量名前面有下划线)直接访问实例变量应该尽量避免，除了在初始化方法(init, initWithCoder:, 等…)，dealloc 方法和自定义的setters和getters。想了解关于如何在初始化方法和dealloc直接使用Accessor方法的更多信息，查看这里。

应该：

[cpp]  view plain copy
  1. @interface RWTTutorial : NSObject  
  2. @property (strong, nonatomic) NSString *tutorialName;  
  3. @end  

不应该：

[cpp]  view plain copy
  1. @interface RWTTutorial : NSObject {  
  2.   NSString *tutorialName;  
  3. }  

属性特性

所有属性特性应该显式地列出来，有助于新手阅读代码。属性特性的顺序应该是storage、atomicity，与在Interface Builder连接UI元素时自动生成代码一致。

应该：

[cpp]  view plain copy
  1. @property (weak, nonatomic) IBOutlet UIView *containerView;  
  2. @property (strong, nonatomic) NSString *tutorialName;  

不应该：

[cpp]  view plain copy
  1. @property (nonatomic, weak) IBOutlet UIView *containerView;  
  2. @property (nonatomic) NSString *tutorialName;  

NSString应该使用copy而不是strong的属性特性。

为什么？即使你声明一个NSString的属性，有人可能传入一个NSMutableString的实例，然后在你没有注意的情况下修改它。

应该：

[cpp]  view plain copy
  1. @property (copy, nonatomic) NSString *tutorialName;  

不应该：

[cpp]  view plain copy
  1. @property (strong, nonatomic) NSString *tutorialName;  

点符号语法

点语法是一种很方便封装访问方法调用的方式。当你使用点语法时，通过使用getter或setter方法，属性仍然被访问或修改。想了解更多，阅读这里。

点语法应该**总是**被用来访问和修改属性，因为它使代码更加简洁。[]符号更偏向于用在其他例子。

应该：

[cpp]  view plain copy
  1. objc  
  2. NSInteger arrayCount = [self.array count];  
  3. view.backgroundColor = [UIColor orangeColor];  
  4. [UIApplication sharedApplication].delegate;  

不应该：

[cpp]  view plain copy
  1. NSInteger arrayCount = self.array.count;  
  2. [view setBackgroundColor:[UIColor orangeColor]];  
  3. UIApplication.sharedApplication.delegate;  

字面值

NSString、NSDictionary、NSArray和NSNumber的字面值应该在创建这些类的不可变实例时被使用。请特别注意nil值不能传入NSArray和NSDictionary字面值，因为这样会导致crash。

应该：

[cpp]  view plain copy
  1. NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];  
  2. NSDictionary *productManagers = @{@"iPhone": @"Kate", @"iPad": @"Kamal", @"Mobile Web": @"Bill"};  
  3. NSNumber *shouldUseLiterals = @YES;  
  4. NSNumber *buildingStreetNumber = @10018;  

不应该:

[cpp]  view plain copy
  1. NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil];  
  2. NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil];  
  3. NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];  
  4. NSNumber *buildingStreetNumber = [NSNumber numberWithInteger:10018];  

常量

常量是容易重复被使用和无需通过查找和代替就能快速修改值。常量应该使用static来声明而不是使用#define，除非显式地使用宏。

应该：

[cpp]  view plain copy
  1. static NSString * const RWTAboutViewControllerCompanyName = @"RayWenderlich.com";  
  2. static CGFloat const RWTImageThumbnailHeight = 50.0;  

不应该：

[cpp]  view plain copy
  1. #define CompanyName @"RayWenderlich.com"  
  2. #define thumbnailHeight 2  

枚举类型

当使用enum时，推荐使用新的固定基本类型规格，因为它有更强的类型检查和代码补全。现在SDK有一个宏NS_ENUM()来帮助和鼓励你使用固定的基本类型。

例如：

[cpp]  view plain copy
  1. typedef NS_ENUM(NSInteger, RWTLeftMenuTopItemType) {  
  2.   RWTLeftMenuTopItemMain,  
  3.   RWTLeftMenuTopItemShows,  
  4.   RWTLeftMenuTopItemSchedule  
  5. };  

你也可以显式地赋值(展示旧的k-style常量定义)：

[cpp]  view plain copy
  1. typedef NS_ENUM(NSInteger, RWTGlobalConstants) {  
  2.   RWTPinSizeMin = 1,  
  3.   RWTPinSizeMax = 5,  
  4.   RWTPinCountMin = 100,  
  5.   RWTPinCountMax = 500,  
  6. };  

旧的k-style常量定义应该避免除非编写Core Foundation C的代码。

不应该：

[cpp]  view plain copy
  1. enum GlobalConstants {  
  2.   kMaxPinSize = 5,  
  3.   kMaxPinCount = 500,  
  4. };  

Case语句

大括号在case语句中并不是必须的，除非编译器强制要求。当一个case语句包含多行代码时，大括号应该加上。

[cpp]  view plain copy
  1. switch (condition) {  
  2.   case 1:  
  3.     // ...  
  4.     break;  
  5.   case 2: {  
  6.     // ...  
  7.     // Multi-line example using braces  
  8.     break;  
  9.   }  
  10.   case 3:  
  11.     // ...  
  12.     break;  
  13.   default:   
  14.     // ...  
  15.     break;  
  16. }  

有很多次，当相同代码被多个cases使用时，一个fall-through应该被使用。一个fall-through就是在case最后移除'break'语句，这样就能够允许执行流程跳转到下一个case值。为了代码更加清晰，一个fall-through需要注释一下。

[cpp]  view plain copy
  1. switch (condition) {  
  2.   case 1:  
  3.     // ** fall-through! **  
  4.   case 2:  
  5.     // code executed for values 1 and 2  
  6.     break;  
  7.   default:   
  8.     // ...  
  9.     break;  
  10. }  

当在switch使用枚举类型时，'default'是不需要的。例如：

[cpp]  view plain copy
  1. RWTLeftMenuTopItemType menuType = RWTLeftMenuTopItemMain;  
  2. switch (menuType) {  
  3.   case RWTLeftMenuTopItemMain:  
  4.     // ...  
  5.     break;  
  6.   case RWTLeftMenuTopItemShows:  
  7.     // ...  
  8.     break;  
  9.   case RWTLeftMenuTopItemSchedule:  
  10.     // ...  
  11.     break;  
  12. }  

私有属性

私有属性应该在类的实现文件中的类扩展(匿名分类)中声明，命名分类(比如RWTPrivate或private)应该从不使用除非是扩展其他类。匿名分类应该通过使用<headerfile>+Private.h文件的命名规则暴露给测试。

例如：

[cpp]  view plain copy
  1. @interface RWTDetailViewController ()  
  2. @property (strong, nonatomic) GADBannerView *googleAdView;  
  3. @property (strong, nonatomic) ADBannerView *iAdView;  
  4. @property (strong, nonatomic) UIWebView *adXWebView;  
  5. @end 



Objective-C使用YES和NO。因为true和false应该只在CoreFoundation，C或C++代码使用。既然nil解析成NO，所以没有必要在条件语句比较。不要拿某样东西直接与YES比较，因为YES被定义为1和一个BOOL能被设置为8位。

这是为了在不同文件保持一致性和在视觉上更加简洁而考虑。

应该：

[cpp]   view plain copy
  1. if (someObject) {}  
  2. if (![anotherObject boolValue]) {}  

不应该：

[cpp]   view plain copy
  1. if (someObject == nil) {}  
  2. if ([anotherObject boolValue] == NO) {}  
  3. if (isAwesome == YES) {} // Never do this.  
  4. if (isAwesome == true) {} // Never do this.  

如果BOOL属性的名字是一个形容词，属性就能忽略"is"前缀，但要指定get访问器的惯用名称。例如：

[cpp]   view plain copy
  1. @property (assign, getter=isEditable) BOOL editable;  

文字和例子从这里引用Cocoa Naming Guidelines。

条件语句

条件语句主体为了防止出错应该使用大括号包围，即使条件语句主体能够不用大括号编写(如，只用一行代码)。这些错误包括添加第二行代码和期望它成为if语句；还有，even more dangerous defect可能发生在if语句里面一行代码被注释了，然后下一行代码不知不觉地成为if语句的一部分。除此之外，这种风格与其他条件语句的风格保持一致，所以更加容易阅读。

应该：

[cpp]   view plain copy
  1. if (!error) {  
  2.   return success;  
  3. }  

不应该：

[cpp]   view plain copy
  1. if (!error)  
  2.   return success;  

或

[cpp]   view plain copy
  1. if (!error) return success;  

三元操作符

当需要提高代码的清晰性和简洁性时，三元操作符?:才会使用。单个条件求值常常需要它。多个条件求值时，如果使用if语句或重构成实例变量时，代码会更加易读。一般来说，最好使用三元操作符是在根据条件来赋值的情况下。

Non-boolean的变量与某东西比较，加上括号()会提高可读性。如果被比较的变量是boolean类型，那么就不需要括号。

应该：

[cpp]   view plain copy
  1. NSInteger value = 5;  
  2. result = (value != 0) ? x : y;  
  3. BOOL isHorizontal = YES;  
  4. result = isHorizontal ? x : y;  

不应该：

[cpp]   view plain copy
  1. result = a > b ? x = c > d ? c : d : y;  

Init方法

Init方法应该遵循Apple生成代码模板的命名规则，返回类型应该使用instancetype而不是id。

[cpp]   view plain copy
  1. - (instancetype)init {  
  2.   self = [super init];  
  3.   if (self) {  
  4.     // ...  
  5.   }  
  6.   return self;  
  7. }  

类构造方法

当类构造方法被使用时，它应该返回类型是instancetype而不是id。这样确保编译器正确地推断结果类型。

[cpp]   view plain copy
  1. @interface Airplane  
  2. + (instancetype)airplaneWithType:(RWTAirplaneType)type;  
  3. @end  

关于更多instancetype信息，请查看NSHipster.com。

CGRect函数

当访问CGRect里的x, y, width, 或 height时，应该使用CGGeometry函数而不是直接通过结构体来访问。引用Apple的CGGeometry：

在这个参考文档中所有的函数，接受CGRect结构体作为输入，在计算它们结果时隐式地标准化这些rectangles。因此，你的应用程序应该避免直接访问和修改保存在CGRect数据结构中的数据。相反，使用这些函数来操纵rectangles和获取它们的特性。

应该：

[cpp]   view plain copy
  1. CGRect frame = self.view.frame;  
  2. CGFloat x = CGRectGetMinX(frame);  
  3. CGFloat y = CGRectGetMinY(frame);  
  4. CGFloat width = CGRectGetWidth(frame);  
  5. CGFloat height = CGRectGetHeight(frame);  
  6. CGRect frame = CGRectMake(0.0, 0.0, width, height);  

不应该：

[cpp]   view plain copy
  1. CGRect frame = self.view.frame;  
  2. CGFloat x = frame.origin.x;  
  3. CGFloat y = frame.origin.y;  
  4. CGFloat width = frame.size.width;  
  5. CGFloat height = frame.size.height;  
  6. CGRect frame = (CGRect){ .origin = CGPointZero, .size = frame.size };  

黄金路径

当使用条件语句编码时，左手边的代码应该是"golden" 或 "happy"路径。也就是不要嵌套if语句，多个返回语句也是OK。

应该：

[cpp]  view plain copy
  1. - (void)someMethod {  
  2.   if (![someOther boolValue]) {  
  3.     return;  
  4.   }  
  5.   //Do something important  
  6. }  

不应该：

[cpp]  view plain copy
  1. - (void)someMethod {  
  2.   if ([someOther boolValue]) {  
  3.     //Do something important  
  4.   }  
  5. }  

错误处理

当方法通过引用来返回一个错误参数，判断返回值而不是错误变量。

应该：

[cpp]  view plain copy
  1. NSError *error;  
  2. if (![self trySomethingWithError:&error]) {  
  3.   // Handle Error  
  4. }  

不应该：

[cpp]  view plain copy
  1. NSError *error;  
  2. [self trySomethingWithError:&error];  
  3. if (error) {  
  4.   // Handle Error  
  5. }  

在成功的情况下，有些Apple的APIs记录垃圾值(garbage values)到错误参数(如果non-NULL)，那么判断错误值会导致false负值和crash。

单例模式

单例对象应该使用线程安全模式来创建共享实例。

[cpp]  view plain copy
  1. + (instancetype)sharedInstance {  
  2.   static id sharedInstance = nil;  
  3.   static dispatch_once_t onceToken;  
  4.   dispatch_once(&onceToken, ^{  
  5.     sharedInstance = [[self alloc] init];  
  6.   });  
  7.   return sharedInstance;  
  8. }  

这会防止possible and sometimes prolific crashes。

换行符

换行符是一个很重要的主题，因为它的风格指南主要为了打印和网上的可读性。

例如：

[cpp]  view plain copy
  1. self.productsRequest = [[SKProductsRequest alloc] initWithProductIdentifiers:productIdentifiers];  

一行很长的代码应该分成两行代码，下一行用两个空格隔开。

[cpp]  view plain copy
  1. self.productsRequest = [[SKProductsRequest alloc]   
  2.   initWithProductIdentifiers:productIdentifiers];  

Xcode工程

物理文件应该与Xcode工程文件保持同步来避免文件扩张。任何Xcode分组的创建应该在文件系统的文件体现。代码不仅是根据类型来分组，而且还可以根据功能来分组，这样代码更加清晰。

尽可能在target的Build Settings打开"Treat Warnings as Errors，和启用以下additional warnings。如果你需要忽略特殊的警告，使用Clang's pragma feature。

其他Objective-C编码规范

如果我们的编码规范不符合你的口味，可以查看其他的编码规范：


wuchangchun12
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Objective-C编码规范：26个方面解决iOS开发问题（转）
weixin_30485799的博客
11-24 73
链接 转载于:https://www.cnblogs.com/YangBinChina/p/4991670.html
【iOS】——基于Vision Kit框架实现图片文字识别
m0_73974920的博客
01-18 2340
根据苹果的官方文档，Vision可以执行面部检测、文本检测、条形码识别、图像注册和一般功能跟踪。Vision还允许将自定义Core ML模型用于分类或对象检测等任务。下面只是对文本识别的一个学习。
iOS开发系列：基于VNRecognizeTextRequest识别图片文字
最新发布
KWMax
05-26 314
在项目设置中点击"General"选项卡，然后在"Frameworks, Libraries, and Embedded Content"（框架、库和嵌入内容）部分，点击"+"按钮。搜索并选择"Vision.framework"。
iOS Objective-C 编码规文档
09-12
Objective-C是iOS开发的核心编程语言，良好的编码规范能提升代码的可读性、可维护性，使团队协作更为高效。以下是对iOS Objective-C编码规范的详细说明： 1. **语言选择**： 在编写Objective-C代码时，建议使用...
iOS Objective C编码规范
09-12
iOS Objective-C编码规范是一套详细的编程标准和习惯用法，旨在提高iOS开发中使用Objective-C语言编写的源代码的可读性和一致性。以下详细阐述了编码规范的核心要点： 1. 代码组织：使用#pragma mark -来对代码进行...
Google的Objective-C编码规范
06-21
Objective-C是一种基于C语言的扩展，强调动态特性和面向对象设计，是Mac OS X和iOS开发的主要语言。Cocoa是Mac OS X的主要应用框架，包含一系列Objective-C类，用于快速构建功能丰富的OS X应用程序。Apple提供了一套...
纽约时报 移动团队 Objective-C 规范指南
03-06
纽约时报移动团队的Objective-C规范指南旨在为iOS开发人员提供一套明确的代码编写准则。该指南详细介绍了Objective-C编程语言的最佳实践，并强调了一些重要的编码习惯，这些习惯能够帮助开发者写出更高质量、更易于...
Objective-C_编码规范
03-25
### Objective-C 编码规范详解 #### 一、引言 Objective-C 是一种通用、面向对象的编程语言，由苹果公司在其操作系统上广泛使用。它结合了C语言的基础语法和Smalltalk的面向对象特性，是iOS和macOS开发的重要工具...
ios swiftui_使用SwiftUI在iOS上进行设备上文本识别
weixin_26638123的博客
07-23 897
ios swiftuiOne of the greatest powers of Apple’s iOS platform is the diversity of built-in frameworks. There are many gems to be found which provide easy-to-use but advanced functionality. One of thes...
Objective-C 学习笔记（三） Xcode操作技巧
smilelance的移动开发专栏
07-21 2423
<br />1、通过xcode新建Objective-C源文件时，可以勾选同时生成.h文件这个功能，在我这xcode是自动被勾选的<br /> <br />2、代码自动完成，xcode的代码自动完成功能也不错<br />2.1、括号匹配，通常你下前一个‘[’的时候，后面的‘]’会自动生成<br />2.2、还有比较便利的是，调用方法的时候，会自动补充所有的变量，你只需要写完第一个参数后按Tab键，xcdoe就会自动跳转到输入下个参数的地方，并替你完成参数的标识<br />2.3、Esc键可以直接跳出提示，当
Object-C使用笔记: XCode5使用中碰到的小问题
一个工具的觉悟
11-25 942
1.  编译时错误提示: Undefined symbols for architecture x86_64: "_iconv_open", referenced from...... 　　原因: 缺少相应的库文件, 需要加入库. ( 在 项目.xcodeproj -> Targets(你的目标) -> Build Phases -> Link Binary With Libraries 中
Mac XCode链接苹果手机iPhone总是不断连接断开、断断续续的解决方法
q345911572的博客
04-07 5542
在iOS开发的过程中，iPhone手机连接Mac电脑之后， 经常出现反复连接上又断开又连接上断开的反复过程， 或者在XCode编译在手机上运行起来之后就连接断开的问题， 原因是Mac的USB接口经常无法提供正常电压的原因（实际提供的低于所需要的） 这里给出2种解决办法： 1.终端运行命令：sudo killall -STOP -c usbd 2.使用扩展坞：扩展坞可以强行增大电压 一般使用第一种...
ios view控件手势拖动
BusyMonkey
06-24 3220
@property (weak, nonatomic) IBOutlet UIView *dragView;//可以是UIView的子类 @property (nonatomic, strong) UIPanGestureRecognizer *panGestureRecognizer;//添加在视图上的拖动手势 @property (weak, nonatomic) IBOutlet UIBut...
IOS Objective-C 蓝牙模块开发经验
weixin_34362790的博客
11-05 445
核心蓝牙框架可让您的iOS和Mac应用程序与蓝牙低功耗设备进行通信。例如，您的应用可以发现，探索和与低能量外围设备进行交互，例如心率监测器，数字恒温器，甚至其他iOS设备。 该框架是蓝牙4.0规范的抽象，用于低能耗设备。也就是说，它隐藏了开发人员对规范的许多低级细节，使您更容易开发与蓝牙低功耗设备交互的应用程序。由于该框架基于规范，因此采用了规范中的一些概念和术语。本章向您介绍使用Core Blu...
Objective-C语法快速参考
Utensil的专栏
12-23 2823
Utensil按：对wxWidgets的Mac Port一直相当不满意。无奈中间隔着Objective-C这一层，今天逛到这篇文章，赶紧转贴过来，扫个最初的盲先。原文来自http://www.cocoachina.com/Objective-C语法快速参考作者: Cocoa China 【最热的Mac, iPhone专业开发论坛】【本文永久地址】10Apr
IOS Objective-c 蓝牙开发教程一蓝牙的连接
说不说
04-08 6558
一开始使用swift连接蓝牙，接收数据，但是因为需求又改成用oc写了，写了swift再写oc非常快的！      开发蓝牙，首先要理解几个概念什么是中心（centrol）什么是周边（peripheral）,这些比较基础百度一下就行。有了这些基本概念以后再上手会快些；      首先从targets------>Build Phases------>导入corebluetooth.framewo
IOS 学习笔记 WebView
无问西东的博客
04-17 5617
笔记记录了WKWebView的使用和遇到的一些问题，以及怎么熟悉的使用xcode进行基本开发，对OC的的熟悉，同时有gif图生动的展示效果
纽约时报iOS团队Objective-C编码规范
"纽约时报移动团队的Objective-C规范指南提供了该团队在开发iOS应用时遵循的编码约定，包括点语法、间距、条件判断等多个方面的详细规则。这份指南旨在提高代码的可读性和一致性，同时也参考了苹果官方的编程语言、...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值