拜移动大潮所赐，这两年Objective-C可谓是风头正茂，连续两年获得年度编程宝座，然而任何一门编程语言也不是十全十美的，这不，这个备受苹果公司关注的Objective-C也不招人待见，原文作者Ash发表一篇博客例举了Objective-C七宗罪。
以下是译文：
如果你正在编写Objective-C代码，那么这篇文章可能会得罪你；倘若还没，那么你无需担心，本文我们一起来细数下Objective-C的七宗罪。
一宗罪：.xib文件太大
我之所以说Objective-C不好，有几个原因，***的问题是当系统加载系统.xib时，需要加载整个.xib；并且在启动应用程序或者用户交互响应环节时占据大量时间，这一点很让人头疼。
第二个问题是，无法重复使用视图（或者与它相关联的代码），你总不会希望一直重复粘贴与复制吧。
二宗罪：无法使点语法保持一致
谈及Objective-C的语法，很多开发者***感觉就变成望而却步了。
许多开发者总认为使用点语法编写是主观现象，也许他们的想法是正确的。但是我个人认为点语法是一个较为现代化的方式来访问属性，这不属于客观现象。相反，如果你选择使用点语法，并且一直坚持这么做。那么，建议你要么全部使用，要么干脆不要，记住，千万不要混合及匹配使用 。
三宗罪：.m Files中的类繁多
在一个相同的文件里会出现很多类，这是一个很主观的现象，因为这往往会利用一个有用的方式来定义，就如同小包装模型类或者值转换。
如果外部文件需要使用你的新类，把它放在自己的文件夹中即可。如果你#import一个视图控制器仅仅是为了在.m file里面得到一个辅助类，那么要把重构摆在首位。
四宗罪：无法进行编译器优化测试
当你开发时通常会使用Xcode默认选项——关闭优化，但最终发布前肯定还是会开启它的，这时经常会出严重的问题。
你无需调优编译器来做完整的回归测试，只需一个简单的smoke测试就足够了。如果你有beta测试人员，那么可以进行设置，重要的是某人在测试之外能够生成二进制文件以确保用户能够被控制。
五宗罪：体系结构的基本类型
Objective-C这门语言以及其运行时既是为iOS，也是为OS X而开发的。但iOS 32位而OS X是64位的。当你使用Objective-C定义原始值的时，使用int将会出现丢失；如同为OS X编译时出现的那些半位，使用long int又显得太蠢了。
六宗罪：不必要的-C APIs
什么是Keychain API？新的OS X APIs需要使用Sandboxing，但需要使用C吗？这里我讨论的不是核心基础类，而是一些严重混乱的C。
C语言比Objective-C快不了多少。如果你想做任何实时系统方面或者处理音频或视频，可选择使用C。在大多数情况下Objective-C是不错的选择。
七宗罪：无法使用自动化测试
你是否使用Objective-C进行单元测试？也许你不曾使用过。那么你曾给UI进行自动化验证测试吗？答案也是NO。那你曾设置过任何持续集成吗？
我不理解Objective-C社区为什么要回避这个问题？要知道这是一个严重的、 系统性的问题。最近我才开始单元测试，我和我的同事在探索UI自动化验收测试。没人知道它是这么的难，也许是因为没人做过，以致没有这方面的资源。因此，我们必须靠自己。文档是编写代码的重要组成部分，我花了整整一天的时间才弄清楚模拟对象是什么，更遑论如何使用它们。
这对于Objective-C社区来说是个严重的问题。此外，单元测试也值得重视且应该将其做好。
英文出自：Ashfurrow
【编辑推荐】
