Swift：常见错误无人问津-宏和指令

您好，我亲爱的开发人员，

我有个故事要告诉你。 从前我很无聊。 那时我像往常一样在课堂上玩耍，用猕猴桃为他们编写测试。 我偶然发现了一个有趣的问题，我真的很想为块模拟，以删除不必要的样板。 可悲的是，没有人开源。 所以我想，为什么不写呢？ 具有一些非常有趣的功能的请求不会伤害我或整个社区。 因此，我开始实施代码，并在重构和挖掘运行时库的过程中发现了很多奇怪的事情。 可悲的是，故事并没有很好地结束，因为当我提交请求请求时，维护人员决定停止添加任何具有大型功能的新功能。 而且我就像FFFFFFUUUUUUUUUUUUUUUUUUUU…。因为在接受请求请求之前，我开始在项目中使用该Kiwi功能，这意味着我必须维护并行分支。 我的故事。 那好吧…

尽管如此，在这段旅程中，我发现代码中散布着一件有趣的事情：

  #if KW_TARGET_HAS_INVOCATION_EXCEPTION_BUG 
  @尝试{ 
  #endif // #if KW_TARGET_HAS_INVOCATION_EXCEPTION_BUG 
  ... 
  #if KW_TARGET_HAS_INVOCATION_EXCEPTION_BUG 
  } @catch（NSException * exception）{ 
  KWSetExceptionFromAcrossInvocationBoundary（exception）; 
  } 
  #endif // #if KW_TARGET_HAS_INVOCATION_EXCEPTION_BUG 

如果看一看，您会发现它分散在整个代码中，但是它具有清晰的模式。 对我们来说，这意味着应该删除重复数据。 为什么，因为从表面上看，这种黑客不再存在，但是将其从代码库中删除真的很困难，因为代码绝不是孤立的。 而且，从我收集到的信息来看，不再需要这种hack（我不知道它的引入原因，但是在禁用它的情况下测试不会失败，至少看起来像这样，因为我没有进行深入研究） 。

您不应该认为这是针对猕猴桃的怨言，因为事实并非如此。 Kiwi令人敬畏，它的开发人员和维护人员构建了我多年来使用的工具，并且在编写ObjC代码时仍在使用。

阅读完代码后，我决定不想自己碰到此类问题，因此我添加了一条准则，使所有特定于宏的代码隔离。 如果我们将该准则应用于我专门为您编写的错误代码：

这不是唯一迅速解决的具体问题。 它们有很多，甚至没有用＃标记。 因此，对于此类代码，更好的措施是至少将其隔离为单独的功能。

但是，这也不是最好的主意。 为什么？ 我们在整个代码中具有不同的特定操作，这导致我们遇到#if os（iOS）的相同问题，该问题既重复又难以重构。 因此，更好的方法是使用与注入闭包和隔离此类代码相同的方式进行操作：

您可以在以前的演讲中读到更多有关注射的信息：

没人管的常见错误– Swift扩展
最糟糕的编码方式。 担心Swift扩展没有被使用。 您好，我亲爱的开发人员… blog.idapgroup.com

就是这样，伙计们。 祝您有美好的一天，无论您身在何处，都要保持干燥。