你在编写Objective-C和Cocoa时使用的最佳实践是什么？ [英] What are best practices that you use when writing Objective-C and Cocoa?
问题描述
我知道 HIG （这是相当方便！），但是你在编写Objective-C时使用什么编程实践，更具体地说，当使用Cocoa（或CocoaTouch）。
I know about the HIG (which is quite handy!), but what programming practices do you use when writing Objective-C, and more specifically when using Cocoa (or CocoaTouch).
推荐答案
有些事情我已经开始做，我不认为是标准的：
There are a few things I have started to do that I do not think are standard:
1）随着属性的出现，我不再使用_前缀私有类变量。毕竟，如果一个变量可以被其他类访问不应该有一个属性呢？
1) With the advent of properties, I no longer use "_" to prefix "private" class variables. After all, if a variable can be accessed by other classes shouldn't there be a property for it? I always disliked the "_" prefix for making code uglier, and now I can leave it out.
2）说到私有的东西，我宁愿放置私有的方法定义在类扩展中的.m文件中：
2) Speaking of private things, I prefer to place private method definitions within the .m file in a class extension like so:
#import "MyClass.h"
@interface MyClass ()
- (void) someMethod;
- (void) someOtherMethod;
@end
@implementation MyClass
为什么混乱.h文件与外人不应该关心的事情？ empty（）适用于.m文件中的私有类别，如果你没有实现声明的方法，就会产生编译警告。
Why clutter up the .h file with things outsiders should not care about? The empty () works for private categories in the .m file, and issues compile warnings if you do not implement the methods declared.
在.m文件的顶部，正好在@synthesize指令下面。应该不是你dealloc是在你想在一个类中想到的事情的列表的顶部？这在iPhone之类的环境中尤其如此。
3) I have taken to putting dealloc at the top of the .m file, just below the @synthesize directives. Shouldn't what you dealloc be at the top of the list of things you want to think about in a class? That is especially true in an environment like the iPhone.
3.5）在表格单元格中，使每个元素（包括单元格本身）不透明以提高性能。
3.5) In table cells, make every element (including the cell itself) opaque for performance. That means setting the appropriate background color in everything.
3.6）当使用NSURLConnection时，你可能希望实现委托方法：
3.6) When using an NSURLConnection, as a rule you may well want to implement the delegate method:
- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
willCacheResponse:(NSCachedURLResponse *)cachedResponse
{
return nil;
}
我发现大多数网络电话都很奇怪，您将需要缓存的响应，特别是对于Web服务调用。实现方法如图所示禁用缓存响应。
I find most web calls are very singular and it's more the exception than the rule you'll be wanting responses cached, especially for web service calls. Implementing the method as shown disables caching of responses.
还有一些好的iPhone的特定提示从Joseph Mattiello（在iPhone邮件列表中收到）。还有更多，但这些是最普遍有用的我想（注意，一些位现在已经从原来的轻微编辑包括响应中提供的详细信息）：
Also of interest, are some good iPhone specific tips from Joseph Mattiello (received in an iPhone mailing list). There are more, but these were the most generally useful I thought (note that a few bits have now been slightly edited from the original to include details offered in responses):
4）如果你必须使用双精度，例如在使用CoreLocation时。确保你以'f'结束你的常量，使gcc将它们存储为浮动。
4) Only use double precision if you have to, such as when working with CoreLocation. Make sure you end your constants in 'f' to make gcc store them as floats.
float val = someFloat * 2.2f;
当 someFloat 是一个双精度型，你不需要混合模式数学，因为你在存储上失去了精度。虽然iPhone上的硬件支持浮点数，但与单精度相比，执行双精度算术可能需要更多时间。参考文献：
This is mostly important when someFloat may actually be a double, you don't need the mixed-mode math, since you're losing precision in 'val' on storage. While floating-point numbers are supported in hardware on iPhones, it may still take more time to do double-precision arithmetic as opposed to single precision. References:
- Double vs float on the iPhone
- iPhone/iPad double precision math
在旧手机上，计算运算速度相同，在寄存器中有更多的单精度元素，而对于许多计算，单精度的结果会更快。
On the older phones supposedly calculations operate at the same speed but you can have more single precision components in registers than doubles, so for many calculations single precision will end up being faster.
5）将属性设置为 。默认情况下它们是 atomic ，在合成时，将创建信号量代码以防止多线程问题。 99％的人可能不需要担心这一点，当设置为非原子时，代码不那么blo肿和更高的内存效率。
5) Set your properties as nonatomic. They're atomic by default and upon synthesis, semaphore code will be created to prevent multi-threading problems. 99% of you probably don't need to worry about this and the code is much less bloated and more memory-efficient when set to nonatomic.
6）SQLite可以一种非常，非常快速的方式来缓存大数据集。地图应用程序实例可以将其图块缓存到SQLite文件中。最昂贵的部分是磁盘I / O。通过在大块之间发送 BEGIN; 和 COMMIT; 来避免许多小写。我们使用2秒定时器，例如在每次新提交时重置。当它到期时，我们发送COMMIT; ，这将导致所有的写入进入一个大块。 SQLite将事务数据存储到磁盘并执行此操作开始/结束包装避免创建许多事务文件，将所有事务分组到一个文件中。
6) SQLite can be a very, very fast way to cache large data sets. A map application for instance can cache its tiles into SQLite files. The most expensive part is disk I/O. Avoid many small writes by sending BEGIN; and COMMIT; between large blocks. We use a 2 second timer for instance that resets on each new submit. When it expires, we send COMMIT; , which causes all your writes to go in one large chunk. SQLite stores transaction data to disk and doing this Begin/End wrapping avoids creation of many transaction files, grouping all of the transactions into one file.
GUI如果它在你的主线程。如果您有一个很长的查询，最好将查询存储为静态对象，并在单独的线程上运行SQL。确保在 @synchronize（）{} 块中的查询字符串中包含修改数据库的任何内容。对于简短的查询，只需在主线程上留下更简单的东西。
Also, SQL will block your GUI if it's on your main thread. If you have a very long query, It's a good idea to store your queries as static objects, and run your SQL on a separate thread. Make sure to wrap anything that modifies the database for query strings in @synchronize() {} blocks. For short queries just leave things on the main thread for easier convenience.
更多SQLite优化提示在这里，虽然文档显示过时很多点可能仍然好;
More SQLite optimization tips are here, though the document appears out of date many of the points are probably still good;
http： //web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html
这篇关于你在编写Objective-C和Cocoa时使用的最佳实践是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
