修订部分内容

translation/1-前言.md

@@ -3,15 +3,15 @@
 We started writing this book on November 2013. The initial goal was to provide guidelines to write the most clean Objective-C code possible: there are too many guidelines out there and all of them are debatable. We didn't aim introducing hard rules but, instead, a way for writing code to be more uniform as possible across different developers.
 With time the scope moved to explain how to design and architecture good code.
 
-我们在2013年11月份开始写这本书，最初的目标是提供一份编写干净漂亮的 Objective-C 代码的指南：现在虽然有很多指南，但是它们都是有一些问题的。我们不想介绍一些死板的规定，我们想提供一个在不同开发者之间能达成统一的写代码的方法。随时间的推移，这本书开始转向介绍如何设计和构建优秀的代码。
+我们在 2013 年 11 月份开始写这本书，最初的目标是提供一份编写干净漂亮的 Objective-C 代码的指南：现在虽然有很多指南，但是它们都是有一些问题的。我们不想介绍一些死板的规定，我们想提供一个在不同开发者之间能一致的写代码的方法。随时间的推移，这本书开始转向介绍如何设计和构建优秀的代码。
 
 The idea underneath is that the code should not only compile, instead it should "validate". Good code has several characteristics: should be concise, self-explanatory, well organized, well documented, well named, well designed and stand the test of time.
 The main goals behind the curtain are that clarity always wins over performance and a rationale for a choice should always be provided.
 Some topics discussed here are general and independent from the language even if everything is tied up to Objective-C.
 
 这本书的理念是代码不仅是可以编译的，同时应该是 “有效” 的。好的代码有一些特性：简明，自我解释，优秀的组织，良好的文档，良好的命名，优秀的设计以及经得起时间的考验。
-这本书的理念是是清晰性优先于性能，并且提供为什么应该这么做的原因。
-即使所有的代码都是 Objective-C 写的，但是一些主题是通用的并且独立于编程语言的。
+这本书的理念是是代码的清晰性优先于性能，同时提供为什么这么做的原因。
+虽然所有的代码都是 Objective-C 写的，但是一些主题是通用的并且独立于编程语言的。
 
 ## Swift
 
@@ -21,15 +21,15 @@ Objective-C is not going anywhere but at the same time continuing to write a boo
 
 在2014年6月6日，苹果发布了面向 iOS 和 Mac 开发的新语言： Swift。
 这个新语言与  Objective-C 截然不同，所以，也改变了我们书写这本书的计划，我们决定发布这本书当前的状态，而不是继续书写我们原来计划写下去的主题。
-Objective-C 没有消失， 但是现在用一个慢慢失去关注的语言来继续写这本书并不是一个明智的选择。
+Objective-C 没有消失，但是现在用一个慢慢失去关注的语言来继续写这本书并不是一个明智的选择。
 
 ## For the Community 关于社区
 
 We have released this book for free and for the community because we hope to provide value to the reader, if each one of you can learn at least one best practice we have reached our goal.
 
 We have done our best to polish this text and make it pleasant to the reader but we may have made typos, mistakes or left any part incomplete. We strongly encourage you to give us feedback and suggest improvements, so please get in touch with us if have any. We particularly appreciate pull requests.
 
-我们将这本书免费发布并且贡献给社区，因为我们希望提供给读者一些有价值的内容。如果你能学到至少一条最佳实践，我们的目标就达到了。
+我们将这本书免费发布并且贡献给社区，因为我们希望提供给读者一些有价值的内容。如果你能学到至少一条最佳实践，我们的目的就达到了。
 
 我们已经非常用心地打磨了这些文字，但是仍然可能有一些拼写或者其他错误。我们非常希望读者给我们一个反馈或者建议，以来改善本书。所以如果有什么问题的话，请联系我们。我们非常欢迎各种 pull-request。
 

translation/10-代码组织.md

@@ -9,7 +9,7 @@
 
 We could not agree more. Having you code clearly organized in a clean and defined manner is a way to show respect for yourself and other people that will read and change you code (consider the future you included).
 
-我们十分赞成。你是否能清晰地组织代码，以及定义的习惯，是你对你自己以及其他看你代码的人的尊重。
+我们十分赞成这句话。清晰地组织代码和规范地进行定义是你对自己以及其他看代码的人的尊重。
 
 ## Exploit Code Block 利用代码块
 
@@ -100,7 +100,7 @@ Be aware that even though the use of pragma mark is a sign of craftsmanship, it'
 
 
 上面的标记能显示分离和组织代码。一个优点是你可以用  cmd+Click 来快速跳转到符号定义地方。
-但是小心，即使paragma mark 是一门手艺，但是它不是让你类里面方法数量增加的一个理由：有太多方法说明你的类做了太多事情，需要考虑重构了。
+但是小心，即使 paragma mark 是一门手艺，但是它不是让你类里面方法数量增加的一个理由：有太多方法说明你的类做了太多事情，需要考虑重构了。
 
 ### Notes about pragma 关于 pragma
 
@@ -110,7 +110,7 @@ At http://raptureinvenice.com/pragmas-arent-just-for-marks there's a great discu
 
 While most iOS developers don't play around much with compiler options, some options are useful to control how strictly to check (or not check) your code for errors. Sometimes, though, you want to make an exception directly in your code using a pragma, which purpose is to temporarily disable a compiler behavior.
 
-当大多数 iOS 开发者没有做很多编译器选项的时候，一些选项是对控制严格检查（或者不检查）你的代码或者错误的。有时候，你想要用 pragma 直接产生一个异常，临时打断编译器的行为。
+大多数 iOS 开发者平时并没有和很多编译器选项打交道。一些选项是对控制严格检查（或者不检查）你的代码或者错误的。有时候，你想要用 pragma 直接产生一个异常，临时打断编译器的行为。
 
 When you use ARC, the compiler inserts memory-management calls for you. There are cases, though, where it can get confused. One such case is when you use `NSSelectorFromString` to have a dynamically-named selector called. Since ARC can't know what the method will be and what kind of memory management to use, you'll be warned with `performSelector may cause a leak because its selector is unknown`.